<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Ssreepa</id>
	<title>Expertiza_Wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Ssreepa"/>
	<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Special:Contributions/Ssreepa"/>
	<updated>2026-06-06T07:36:47Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.41.0</generator>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54240</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54240"/>
		<updated>2011-10-28T23:24:49Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Proc.new */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism).Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures &amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt;help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}   #define lambda proc&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a                 #call proc object&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new&amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/ Proc and Lamda]&amp;lt;/ref&amp;gt; takes in a block and returns a Proc object which will run the code in the block when call method is invoked. In Proc.new created proc the return control is from the method enclosing the Proc.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method.In a lambda created proc, the return statement returns only from the proc itself. This is the difference from the Proc.new created proc.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for the addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]                        #original addition function add&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry              #curried function curried_add &lt;br /&gt;
add_to_ten = curried_add[10]         #only 1 number specified to curried function curried_add, by fixing one of the input values&lt;br /&gt;
add_to_twenty = curried_add[20]      #thus the curried function always adds 10 and 20 to the second number when we use it with&lt;br /&gt;
                                     #add_to_ten  and add_to_twenty respectively&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]                   #adding second number 5 to the fixed value of 10&lt;br /&gt;
puts add_to_twenty[5]                #adding second number 5 to the fixed value of 20&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class&amp;lt;ref&amp;gt;[http://phrogz.net/programmingruby/tut_classes.html Ruby Classes]&amp;lt;/ref&amp;gt; methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock                   #BookInStock is a class name&lt;br /&gt;
    def initialize(isbn, price)       #initialize is used to initialize instance variables&lt;br /&gt;
       @isbn = isbn                   #@isbn and @price are instance variables&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book                     #self denotes class method&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
  class ParkingLot                  &lt;br /&gt;
    def initialize(n)&lt;br /&gt;
      @spotsAvailable = n                     #initialize the variable&lt;br /&gt;
    end&lt;br /&gt;
    def park                                      &lt;br /&gt;
      puts &amp;quot;Park your car&amp;quot;&lt;br /&gt;
      @spotsAvailable = @spotsAvailable - 1   #decrement the number of available slots&lt;br /&gt;
    end&lt;br /&gt;
    def unpark&lt;br /&gt;
      puts &amp;quot;Unpark your car&amp;quot;&lt;br /&gt;
      @spotsAvailable = @spotsAvailable + 1   #increment the available slots&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. There is another example of class ParkingLot which has two methods defined, park and unpark. It maintains the number of available spots in the ParkingLot. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor&amp;lt;ref&amp;gt;[http://www.rubyist.net/~slagell/ruby/accessors.html Accessors]&amp;lt;/ref&amp;gt;. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title       #getter method&lt;br /&gt;
    attr_writer :price       #setter method&lt;br /&gt;
    attr_accessor : isbn     #getter and setter methods &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of [http://download.oracle.com/javase/tutorial/java/IandI/abstract.html abstract methods]. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) #raise indicates exception&lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing&amp;lt;ref&amp;gt;[http://rubylearning.com/satishtalim/duck_typing.html Duck Typing]&amp;lt;/ref&amp;gt;. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing]in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.tutorialspoint.com/ruby/ruby_classes.htm Ruby Classes]&lt;br /&gt;
*[http://rubysource.com/ruby-mixins-2/ Ruby Inheritance]&lt;br /&gt;
*[http://pragdave.blogs.pragprog.com/pragdave/2008/09/fun-with-procs.html Ruby Procs]&lt;br /&gt;
*[http://moonbase.rydia.net/mental/blog/programming/currying-in-ruby Currying]&lt;br /&gt;
*[http://www.robertsosinski.com/2008/12/21/understanding-ruby-blocks-procs-and-lambdas/ Procs, Blocks and Lambdas]&lt;br /&gt;
*[http://moonmaster9000.tumblr.com/post/477872071/class-variables-and-inheritance-in-ruby Class variables and Inheritance]&lt;br /&gt;
*[http://blog.rubybestpractices.com/posts/gregory/047-issue-15-duck-typing-2.html Best Practices]&lt;br /&gt;
*[http://rubysource.com/making-ruby-quack%E2%80%94why-we-love-duck-typing/ Duck Typing]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Programming Ruby, The Pragmatic Programmer's Guide by Dave Thomas&lt;br /&gt;
* Design Java by Dale Skrien&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54239</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54239"/>
		<updated>2011-10-28T23:23:37Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Class */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism).Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures &amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt;help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}   #define lambda proc&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a                 #call proc object&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new&amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/ proc and Lamda]&amp;lt;/ref&amp;gt; takes in a block and returns a Proc object which will run the code in the block when call method is invoked. In Proc.new created proc the return control is from the method enclosing the Proc.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method.In a lambda created proc, the return statement returns only from the proc itself. This is the difference from the Proc.new created proc.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for the addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]                        #original addition function add&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry              #curried function curried_add &lt;br /&gt;
add_to_ten = curried_add[10]         #only 1 number specified to curried function curried_add, by fixing one of the input values&lt;br /&gt;
add_to_twenty = curried_add[20]      #thus the curried function always adds 10 and 20 to the second number when we use it with&lt;br /&gt;
                                     #add_to_ten  and add_to_twenty respectively&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]                   #adding second number 5 to the fixed value of 10&lt;br /&gt;
puts add_to_twenty[5]                #adding second number 5 to the fixed value of 20&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class&amp;lt;ref&amp;gt;[http://phrogz.net/programmingruby/tut_classes.html Ruby Classes]&amp;lt;/ref&amp;gt; methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock                   #BookInStock is a class name&lt;br /&gt;
    def initialize(isbn, price)       #initialize is used to initialize instance variables&lt;br /&gt;
       @isbn = isbn                   #@isbn and @price are instance variables&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book                     #self denotes class method&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
  class ParkingLot                  &lt;br /&gt;
    def initialize(n)&lt;br /&gt;
      @spotsAvailable = n                     #initialize the variable&lt;br /&gt;
    end&lt;br /&gt;
    def park                                      &lt;br /&gt;
      puts &amp;quot;Park your car&amp;quot;&lt;br /&gt;
      @spotsAvailable = @spotsAvailable - 1   #decrement the number of available slots&lt;br /&gt;
    end&lt;br /&gt;
    def unpark&lt;br /&gt;
      puts &amp;quot;Unpark your car&amp;quot;&lt;br /&gt;
      @spotsAvailable = @spotsAvailable + 1   #increment the available slots&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. There is another example of class ParkingLot which has two methods defined, park and unpark. It maintains the number of available spots in the ParkingLot. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor&amp;lt;ref&amp;gt;[http://www.rubyist.net/~slagell/ruby/accessors.html Accessors]&amp;lt;/ref&amp;gt;. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title       #getter method&lt;br /&gt;
    attr_writer :price       #setter method&lt;br /&gt;
    attr_accessor : isbn     #getter and setter methods &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of [http://download.oracle.com/javase/tutorial/java/IandI/abstract.html abstract methods]. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) #raise indicates exception&lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing&amp;lt;ref&amp;gt;[http://rubylearning.com/satishtalim/duck_typing.html Duck Typing]&amp;lt;/ref&amp;gt;. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing]in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.tutorialspoint.com/ruby/ruby_classes.htm Ruby Classes]&lt;br /&gt;
*[http://rubysource.com/ruby-mixins-2/ Ruby Inheritance]&lt;br /&gt;
*[http://pragdave.blogs.pragprog.com/pragdave/2008/09/fun-with-procs.html Ruby Procs]&lt;br /&gt;
*[http://moonbase.rydia.net/mental/blog/programming/currying-in-ruby Currying]&lt;br /&gt;
*[http://www.robertsosinski.com/2008/12/21/understanding-ruby-blocks-procs-and-lambdas/ Procs, Blocks and Lambdas]&lt;br /&gt;
*[http://moonmaster9000.tumblr.com/post/477872071/class-variables-and-inheritance-in-ruby Class variables and Inheritance]&lt;br /&gt;
*[http://blog.rubybestpractices.com/posts/gregory/047-issue-15-duck-typing-2.html Best Practices]&lt;br /&gt;
*[http://rubysource.com/making-ruby-quack%E2%80%94why-we-love-duck-typing/ Duck Typing]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Programming Ruby, The Pragmatic Programmer's Guide by Dave Thomas&lt;br /&gt;
* Design Java by Dale Skrien&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54238</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54238"/>
		<updated>2011-10-28T23:20:03Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Class */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism).Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures &amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt;help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}   #define lambda proc&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a                 #call proc object&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new&amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/ proc and Lamda]&amp;lt;/ref&amp;gt; takes in a block and returns a Proc object which will run the code in the block when call method is invoked. In Proc.new created proc the return control is from the method enclosing the Proc.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method.In a lambda created proc, the return statement returns only from the proc itself. This is the difference from the Proc.new created proc.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for the addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]                        #original addition function add&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry              #curried function curried_add &lt;br /&gt;
add_to_ten = curried_add[10]         #only 1 number specified to curried function curried_add, by fixing one of the input values&lt;br /&gt;
add_to_twenty = curried_add[20]      #thus the curried function always adds 10 and 20 to the second number when we use it with&lt;br /&gt;
                                     #add_to_ten  and add_to_twenty respectively&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]                   #adding second number 5 to the fixed value of 10&lt;br /&gt;
puts add_to_twenty[5]                #adding second number 5 to the fixed value of 20&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class&amp;lt;ref&amp;gt;[http://phrogz.net/programmingruby/tut_classes.html Ruby Classes]&amp;lt;/ref&amp;gt; methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock                   #BookInStock is a class name&lt;br /&gt;
    def initialize(isbn, price)       #initialize is used to initialize instance variables&lt;br /&gt;
       @isbn = isbn                   #@isbn and @price are instance variables&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book                     #self denotes class method&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
  class ParkingLot                  &lt;br /&gt;
    def initialize(n)&lt;br /&gt;
      @spotsAvailable = n&lt;br /&gt;
    end&lt;br /&gt;
    def park                                      &lt;br /&gt;
      puts &amp;quot;Park your car&amp;quot;&lt;br /&gt;
      @spotsAvailable = @spotsAvailable -1&lt;br /&gt;
    end&lt;br /&gt;
    def unpark&lt;br /&gt;
      puts &amp;quot;Unpark your car&amp;quot;&lt;br /&gt;
      @spotsAvailable = @spotsAvailable + 1&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor&amp;lt;ref&amp;gt;[http://www.rubyist.net/~slagell/ruby/accessors.html Accessors]&amp;lt;/ref&amp;gt;. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title       #getter method&lt;br /&gt;
    attr_writer :price       #setter method&lt;br /&gt;
    attr_accessor : isbn     #getter and setter methods &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of [http://download.oracle.com/javase/tutorial/java/IandI/abstract.html abstract methods]. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) #raise indicates exception&lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing&amp;lt;ref&amp;gt;[http://rubylearning.com/satishtalim/duck_typing.html Duck Typing]&amp;lt;/ref&amp;gt;. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing]in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.tutorialspoint.com/ruby/ruby_classes.htm Ruby Classes]&lt;br /&gt;
*[http://rubysource.com/ruby-mixins-2/ Ruby Inheritance]&lt;br /&gt;
*[http://pragdave.blogs.pragprog.com/pragdave/2008/09/fun-with-procs.html Ruby Procs]&lt;br /&gt;
*[http://moonbase.rydia.net/mental/blog/programming/currying-in-ruby Currying]&lt;br /&gt;
*[http://www.robertsosinski.com/2008/12/21/understanding-ruby-blocks-procs-and-lambdas/ Procs, Blocks and Lambdas]&lt;br /&gt;
*[http://moonmaster9000.tumblr.com/post/477872071/class-variables-and-inheritance-in-ruby Class variables and Inheritance]&lt;br /&gt;
*[http://blog.rubybestpractices.com/posts/gregory/047-issue-15-duck-typing-2.html Best Practices]&lt;br /&gt;
*[http://rubysource.com/making-ruby-quack%E2%80%94why-we-love-duck-typing/ Duck Typing]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Programming Ruby, The Pragmatic Programmer's Guide by Dave Thomas&lt;br /&gt;
* Design Java by Dale Skrien&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54235</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54235"/>
		<updated>2011-10-28T23:16:15Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Further reading */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism).Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures &amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt;help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas&amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/ proc and Lamda]&amp;lt;/ref&amp;gt;===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked. In Proc.new created proc the return control is from the method enclosing the Proc.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method.In a lambda created proc, the return statement returns only from the proc itself. This is the difference from the Proc.new created proc.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for the addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]                        #original addition function add&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry              #curried function curried_add &lt;br /&gt;
add_to_ten = curried_add[10]         #only 1 number specified to curried function curried_add, by fixing one of the input values&lt;br /&gt;
add_to_twenty = curried_add[20]      #thus the curried function always adds 10 and 20 to the second number when we use it with&lt;br /&gt;
                                     #add_to_ten  and add_to_twenty respectively&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]                   #adding second number 5 to the fixed value of 10&lt;br /&gt;
puts add_to_twenty[5]                #adding second number 5 to the fixed value of 20&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class&amp;lt;ref&amp;gt;[http://phrogz.net/programmingruby/tut_classes.html Ruby Classes]&amp;lt;/ref&amp;gt; methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock                   #BookInStock is a class name&lt;br /&gt;
    def initialize(isbn, price)       #initialize is used to initialize instance variables&lt;br /&gt;
       @isbn = isbn                   #@isbn and @price are instance variables&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book                     #self denotes class method&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor&amp;lt;ref&amp;gt;[http://www.rubyist.net/~slagell/ruby/accessors.html Accessors]&amp;lt;/ref&amp;gt;. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title       #getter method&lt;br /&gt;
    attr_writer :price       #setter method&lt;br /&gt;
    attr_accessor : isbn     #getter and setter methods &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of [http://download.oracle.com/javase/tutorial/java/IandI/abstract.html abstract methods]. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) #raise indicates exception&lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing&amp;lt;ref&amp;gt;[http://rubylearning.com/satishtalim/duck_typing.html Duck Typing]&amp;lt;/ref&amp;gt;. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing]in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.tutorialspoint.com/ruby/ruby_classes.htm Ruby Classes]&lt;br /&gt;
*[http://rubysource.com/ruby-mixins-2/ Ruby Inheritance]&lt;br /&gt;
*[http://pragdave.blogs.pragprog.com/pragdave/2008/09/fun-with-procs.html Ruby Procs]&lt;br /&gt;
*[http://moonbase.rydia.net/mental/blog/programming/currying-in-ruby Currying]&lt;br /&gt;
*[http://www.robertsosinski.com/2008/12/21/understanding-ruby-blocks-procs-and-lambdas/ Procs, Blocks and Lambdas]&lt;br /&gt;
*[http://moonmaster9000.tumblr.com/post/477872071/class-variables-and-inheritance-in-ruby Class variables and Inheritance]&lt;br /&gt;
*[http://blog.rubybestpractices.com/posts/gregory/047-issue-15-duck-typing-2.html Best Practices]&lt;br /&gt;
*[http://rubysource.com/making-ruby-quack%E2%80%94why-we-love-duck-typing/ Duck Typing]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Programming Ruby, The Pragmatic Programmer's Guide by Dave Thomas&lt;br /&gt;
* Design Java by Dale Skrien&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54234</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54234"/>
		<updated>2011-10-28T23:14:38Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* External links */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism).Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures &amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt;help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas&amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/ proc and Lamda]&amp;lt;/ref&amp;gt;===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked. In Proc.new created proc the return control is from the method enclosing the Proc.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method.In a lambda created proc, the return statement returns only from the proc itself. This is the difference from the Proc.new created proc.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for the addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]                        #original addition function add&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry              #curried function curried_add &lt;br /&gt;
add_to_ten = curried_add[10]         #only 1 number specified to curried function curried_add, by fixing one of the input values&lt;br /&gt;
add_to_twenty = curried_add[20]      #thus the curried function always adds 10 and 20 to the second number when we use it with&lt;br /&gt;
                                     #add_to_ten  and add_to_twenty respectively&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]                   #adding second number 5 to the fixed value of 10&lt;br /&gt;
puts add_to_twenty[5]                #adding second number 5 to the fixed value of 20&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class&amp;lt;ref&amp;gt;[http://phrogz.net/programmingruby/tut_classes.html Ruby Classes]&amp;lt;/ref&amp;gt; methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock                   #BookInStock is a class name&lt;br /&gt;
    def initialize(isbn, price)       #initialize is used to initialize instance variables&lt;br /&gt;
       @isbn = isbn                   #@isbn and @price are instance variables&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book                     #self denotes class method&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor&amp;lt;ref&amp;gt;[http://www.rubyist.net/~slagell/ruby/accessors.html Accessors]&amp;lt;/ref&amp;gt;. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title       #getter method&lt;br /&gt;
    attr_writer :price       #setter method&lt;br /&gt;
    attr_accessor : isbn     #getter and setter methods &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of [http://download.oracle.com/javase/tutorial/java/IandI/abstract.html abstract methods]. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) #raise indicates exception&lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing&amp;lt;ref&amp;gt;[http://rubylearning.com/satishtalim/duck_typing.html Duck Typing]&amp;lt;/ref&amp;gt;. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing]in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.tutorialspoint.com/ruby/ruby_classes.htm Ruby Classes]&lt;br /&gt;
*[http://rubysource.com/ruby-mixins-2/ Ruby Inheritance]&lt;br /&gt;
*[http://pragdave.blogs.pragprog.com/pragdave/2008/09/fun-with-procs.html Ruby Procs]&lt;br /&gt;
*[http://moonbase.rydia.net/mental/blog/programming/currying-in-ruby Currying]&lt;br /&gt;
*[http://www.robertsosinski.com/2008/12/21/understanding-ruby-blocks-procs-and-lambdas/ Procs, Blocks and Lambdas]&lt;br /&gt;
*[http://moonmaster9000.tumblr.com/post/477872071/class-variables-and-inheritance-in-ruby Class variables and Inheritance]&lt;br /&gt;
*[http://blog.rubybestpractices.com/posts/gregory/047-issue-15-duck-typing-2.html Best Practices]&lt;br /&gt;
*[http://rubysource.com/making-ruby-quack%E2%80%94why-we-love-duck-typing/ Duck Typing]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Programming Ruby, The Pragmatic Programmer's Guide by Dave Thomas&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54233</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54233"/>
		<updated>2011-10-28T23:12:57Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* External links */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism).Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures &amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt;help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas&amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/ proc and Lamda]&amp;lt;/ref&amp;gt;===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked. In Proc.new created proc the return control is from the method enclosing the Proc.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method.In a lambda created proc, the return statement returns only from the proc itself. This is the difference from the Proc.new created proc.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for the addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]                        #original addition function add&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry              #curried function curried_add &lt;br /&gt;
add_to_ten = curried_add[10]         #only 1 number specified to curried function curried_add, by fixing one of the input values&lt;br /&gt;
add_to_twenty = curried_add[20]      #thus the curried function always adds 10 and 20 to the second number when we use it with&lt;br /&gt;
                                     #add_to_ten  and add_to_twenty respectively&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]                   #adding second number 5 to the fixed value of 10&lt;br /&gt;
puts add_to_twenty[5]                #adding second number 5 to the fixed value of 20&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class&amp;lt;ref&amp;gt;[http://phrogz.net/programmingruby/tut_classes.html Ruby Classes]&amp;lt;/ref&amp;gt; methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock                   #BookInStock is a class name&lt;br /&gt;
    def initialize(isbn, price)       #initialize is used to initialize instance variables&lt;br /&gt;
       @isbn = isbn                   #@isbn and @price are instance variables&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book                     #self denotes class method&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor&amp;lt;ref&amp;gt;[http://www.rubyist.net/~slagell/ruby/accessors.html Accessors]&amp;lt;/ref&amp;gt;. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title       #getter method&lt;br /&gt;
    attr_writer :price       #setter method&lt;br /&gt;
    attr_accessor : isbn     #getter and setter methods &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of [http://download.oracle.com/javase/tutorial/java/IandI/abstract.html abstract methods]. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) #raise indicates exception&lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing&amp;lt;ref&amp;gt;[http://rubylearning.com/satishtalim/duck_typing.html Duck Typing]&amp;lt;/ref&amp;gt;. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing]in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.tutorialspoint.com/ruby/ruby_classes.htm Ruby Classes]&lt;br /&gt;
*[http://rubysource.com/ruby-mixins-2/ Ruby Inheritance]&lt;br /&gt;
*[http://pragdave.blogs.pragprog.com/pragdave/2008/09/fun-with-procs.html Ruby Procs]&lt;br /&gt;
*[http://moonbase.rydia.net/mental/blog/programming/currying-in-ruby Currying]&lt;br /&gt;
*[http://www.robertsosinski.com/2008/12/21/understanding-ruby-blocks-procs-and-lambdas/ Procs, Blocks and Lambdas]&lt;br /&gt;
*[http://moonmaster9000.tumblr.com/post/477872071/class-variables-and-inheritance-in-ruby class variables and Inheritance]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Programming Ruby, The Pragmatic Programmer's Guide by Dave Thomas&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54232</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54232"/>
		<updated>2011-10-28T23:09:20Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* External links */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism).Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures &amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt;help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas&amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/ proc and Lamda]&amp;lt;/ref&amp;gt;===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked. In Proc.new created proc the return control is from the method enclosing the Proc.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method.In a lambda created proc, the return statement returns only from the proc itself. This is the difference from the Proc.new created proc.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for the addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]                        #original addition function add&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry              #curried function curried_add &lt;br /&gt;
add_to_ten = curried_add[10]         #only 1 number specified to curried function curried_add, by fixing one of the input values&lt;br /&gt;
add_to_twenty = curried_add[20]      #thus the curried function always adds 10 and 20 to the second number when we use it with&lt;br /&gt;
                                     #add_to_ten  and add_to_twenty respectively&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]                   #adding second number 5 to the fixed value of 10&lt;br /&gt;
puts add_to_twenty[5]                #adding second number 5 to the fixed value of 20&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class&amp;lt;ref&amp;gt;[http://phrogz.net/programmingruby/tut_classes.html Ruby Classes]&amp;lt;/ref&amp;gt; methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock                   #BookInStock is a class name&lt;br /&gt;
    def initialize(isbn, price)       #initialize is used to initialize instance variables&lt;br /&gt;
       @isbn = isbn                   #@isbn and @price are instance variables&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book                     #self denotes class method&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor&amp;lt;ref&amp;gt;[http://www.rubyist.net/~slagell/ruby/accessors.html Accessors]&amp;lt;/ref&amp;gt;. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title       #getter method&lt;br /&gt;
    attr_writer :price       #setter method&lt;br /&gt;
    attr_accessor : isbn     #getter and setter methods &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of [http://download.oracle.com/javase/tutorial/java/IandI/abstract.html abstract methods]. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) #raise indicates exception&lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing&amp;lt;ref&amp;gt;[http://rubylearning.com/satishtalim/duck_typing.html Duck Typing]&amp;lt;/ref&amp;gt;. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing]in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.tutorialspoint.com/ruby/ruby_classes.htm Ruby Classes]&lt;br /&gt;
*[http://rubysource.com/ruby-mixins-2/ Ruby Inheritance]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Programming Ruby, The Pragmatic Programmer's Guide by Dave Thomas&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54231</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54231"/>
		<updated>2011-10-28T23:07:52Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Abstract methods */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism).Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures &amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt;help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas&amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/ proc and Lamda]&amp;lt;/ref&amp;gt;===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked. In Proc.new created proc the return control is from the method enclosing the Proc.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method.In a lambda created proc, the return statement returns only from the proc itself. This is the difference from the Proc.new created proc.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for the addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]                        #original addition function add&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry              #curried function curried_add &lt;br /&gt;
add_to_ten = curried_add[10]         #only 1 number specified to curried function curried_add, by fixing one of the input values&lt;br /&gt;
add_to_twenty = curried_add[20]      #thus the curried function always adds 10 and 20 to the second number when we use it with&lt;br /&gt;
                                     #add_to_ten  and add_to_twenty respectively&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]                   #adding second number 5 to the fixed value of 10&lt;br /&gt;
puts add_to_twenty[5]                #adding second number 5 to the fixed value of 20&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class&amp;lt;ref&amp;gt;[http://phrogz.net/programmingruby/tut_classes.html Ruby Classes]&amp;lt;/ref&amp;gt; methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock                   #BookInStock is a class name&lt;br /&gt;
    def initialize(isbn, price)       #initialize is used to initialize instance variables&lt;br /&gt;
       @isbn = isbn                   #@isbn and @price are instance variables&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book                     #self denotes class method&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor&amp;lt;ref&amp;gt;[http://www.rubyist.net/~slagell/ruby/accessors.html Accessors]&amp;lt;/ref&amp;gt;. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title       #getter method&lt;br /&gt;
    attr_writer :price       #setter method&lt;br /&gt;
    attr_accessor : isbn     #getter and setter methods &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of [http://download.oracle.com/javase/tutorial/java/IandI/abstract.html abstract methods]. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) #raise indicates exception&lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing&amp;lt;ref&amp;gt;[http://rubylearning.com/satishtalim/duck_typing.html Duck Typing]&amp;lt;/ref&amp;gt;. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing]in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.tutorialspoint.com/ruby/ruby_classes.htm dsfsfd]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Programming Ruby, The Pragmatic Programmer's Guide by Dave Thomas&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54230</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54230"/>
		<updated>2011-10-28T23:05:45Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Attributes */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism).Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures &amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt;help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas&amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/ proc and Lamda]&amp;lt;/ref&amp;gt;===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked. In Proc.new created proc the return control is from the method enclosing the Proc.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method.In a lambda created proc, the return statement returns only from the proc itself. This is the difference from the Proc.new created proc.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for the addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]                        #original addition function add&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry              #curried function curried_add &lt;br /&gt;
add_to_ten = curried_add[10]         #only 1 number specified to curried function curried_add, by fixing one of the input values&lt;br /&gt;
add_to_twenty = curried_add[20]      #thus the curried function always adds 10 and 20 to the second number when we use it with&lt;br /&gt;
                                     #add_to_ten  and add_to_twenty respectively&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]                   #adding second number 5 to the fixed value of 10&lt;br /&gt;
puts add_to_twenty[5]                #adding second number 5 to the fixed value of 20&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class&amp;lt;ref&amp;gt;[http://phrogz.net/programmingruby/tut_classes.html Ruby Classes]&amp;lt;/ref&amp;gt; methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock                   #BookInStock is a class name&lt;br /&gt;
    def initialize(isbn, price)       #initialize is used to initialize instance variables&lt;br /&gt;
       @isbn = isbn                   #@isbn and @price are instance variables&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book                     #self denotes class method&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor&amp;lt;ref&amp;gt;[http://www.rubyist.net/~slagell/ruby/accessors.html Accessors]&amp;lt;/ref&amp;gt;. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title       #getter method&lt;br /&gt;
    attr_writer :price       #setter method&lt;br /&gt;
    attr_accessor : isbn     #getter and setter methods &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) #raise indicates exception&lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing&amp;lt;ref&amp;gt;[http://rubylearning.com/satishtalim/duck_typing.html Duck Typing]&amp;lt;/ref&amp;gt;. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing]in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.tutorialspoint.com/ruby/ruby_classes.htm dsfsfd]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Programming Ruby, The Pragmatic Programmer's Guide by Dave Thomas&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54225</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54225"/>
		<updated>2011-10-28T20:38:38Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Duck typing (Unbounded Polymorphism) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
In the following wiki, we will be covering the basics of closures and currying. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism). &lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures &amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt;help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas&amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/ proc and Lamda]&amp;lt;/ref&amp;gt;===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for the addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]                        #original addition function add&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry              #curried function curried_add &lt;br /&gt;
add_to_ten = curried_add[10]         #only 1 number specified to curried function curried_add, by fixing one of the input values&lt;br /&gt;
add_to_twenty = curried_add[20]      #thus the curried function always adds 10 and 20 to the second number when we use it with&lt;br /&gt;
                                     #add_to_ten  and add_to_twenty respectively&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]                   #adding second number 5 to the fixed value of 10&lt;br /&gt;
puts add_to_twenty[5]                #adding second number 5 to the fixed value of 20&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class&amp;lt;ref&amp;gt;[http://phrogz.net/programmingruby/tut_classes.html Ruby Classes]&amp;lt;/ref&amp;gt; methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock                   #BookInStock is a class name&lt;br /&gt;
    def initialize(isbn, price)       #initialize is used to initialize instance variables&lt;br /&gt;
       @isbn = isbn                   #@isbn and @price are instance variables&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book                     #self denotes class method&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title       #getter method&lt;br /&gt;
    attr_writer :price       #setter method&lt;br /&gt;
    attr_accessor : isbn     #getter and setter methods &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) #raise indicates exception&lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing&amp;lt;ref&amp;gt;[http://rubylearning.com/satishtalim/duck_typing.html Duck Typing]&amp;lt;/ref&amp;gt;. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing]in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.tutorialspoint.com/ruby/ruby_classes.htm dsfsfd]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Programming Ruby, The Pragmatic Programmer's Guide by Dave Thomas&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54224</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54224"/>
		<updated>2011-10-28T20:38:17Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Duck typing (Unbounded Polymorphism) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
In the following wiki, we will be covering the basics of closures and currying. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism). &lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures &amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt;help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas&amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/ proc and Lamda]&amp;lt;/ref&amp;gt;===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for the addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]                        #original addition function add&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry              #curried function curried_add &lt;br /&gt;
add_to_ten = curried_add[10]         #only 1 number specified to curried function curried_add, by fixing one of the input values&lt;br /&gt;
add_to_twenty = curried_add[20]      #thus the curried function always adds 10 and 20 to the second number when we use it with&lt;br /&gt;
                                     #add_to_ten  and add_to_twenty respectively&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]                   #adding second number 5 to the fixed value of 10&lt;br /&gt;
puts add_to_twenty[5]                #adding second number 5 to the fixed value of 20&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class&amp;lt;ref&amp;gt;[http://phrogz.net/programmingruby/tut_classes.html Ruby Classes]&amp;lt;/ref&amp;gt; methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock                   #BookInStock is a class name&lt;br /&gt;
    def initialize(isbn, price)       #initialize is used to initialize instance variables&lt;br /&gt;
       @isbn = isbn                   #@isbn and @price are instance variables&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book                     #self denotes class method&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title       #getter method&lt;br /&gt;
    attr_writer :price       #setter method&lt;br /&gt;
    attr_accessor : isbn     #getter and setter methods &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) #raise indicates exception&lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing&amp;lt;ref&amp;gt;[http://rubylearning.com/satishtalim/duck_typing.html]&amp;lt;/ref&amp;gt;. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing]in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.tutorialspoint.com/ruby/ruby_classes.htm dsfsfd]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Programming Ruby, The Pragmatic Programmer's Guide by Dave Thomas&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54223</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54223"/>
		<updated>2011-10-28T20:37:37Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Duck typing (Unbounded Polymorphism) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
In the following wiki, we will be covering the basics of closures and currying. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism). &lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures &amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt;help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas&amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/ proc and Lamda]&amp;lt;/ref&amp;gt;===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for the addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]                        #original addition function add&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry              #curried function curried_add &lt;br /&gt;
add_to_ten = curried_add[10]         #only 1 number specified to curried function curried_add, by fixing one of the input values&lt;br /&gt;
add_to_twenty = curried_add[20]      #thus the curried function always adds 10 and 20 to the second number when we use it with&lt;br /&gt;
                                     #add_to_ten  and add_to_twenty respectively&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]                   #adding second number 5 to the fixed value of 10&lt;br /&gt;
puts add_to_twenty[5]                #adding second number 5 to the fixed value of 20&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class&amp;lt;ref&amp;gt;[http://phrogz.net/programmingruby/tut_classes.html Ruby Classes]&amp;lt;/ref&amp;gt; methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock                   #BookInStock is a class name&lt;br /&gt;
    def initialize(isbn, price)       #initialize is used to initialize instance variables&lt;br /&gt;
       @isbn = isbn                   #@isbn and @price are instance variables&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book                     #self denotes class method&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title       #getter method&lt;br /&gt;
    attr_writer :price       #setter method&lt;br /&gt;
    attr_accessor : isbn     #getter and setter methods &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) #raise indicates exception&lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing&amp;lt;ref&amp;gt;[http://rubylearning.com/satishtalim/duck_typing.html&amp;gt;&amp;lt;/ref&amp;gt;. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing]in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.tutorialspoint.com/ruby/ruby_classes.htm dsfsfd]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Programming Ruby, The Pragmatic Programmer's Guide by Dave Thomas&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54221</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54221"/>
		<updated>2011-10-28T20:35:40Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Duck typing (Unbounded Polymorphism) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
In the following wiki, we will be covering the basics of closures and currying. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism). &lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures &amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt;help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas&amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/ proc and Lamda]&amp;lt;/ref&amp;gt;===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for the addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]                        #original addition function add&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry              #curried function curried_add &lt;br /&gt;
add_to_ten = curried_add[10]         #only 1 number specified to curried function curried_add, by fixing one of the input values&lt;br /&gt;
add_to_twenty = curried_add[20]      #thus the curried function always adds 10 and 20 to the second number when we use it with&lt;br /&gt;
                                     #add_to_ten  and add_to_twenty respectively&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]                   #adding second number 5 to the fixed value of 10&lt;br /&gt;
puts add_to_twenty[5]                #adding second number 5 to the fixed value of 20&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class&amp;lt;ref&amp;gt;[http://phrogz.net/programmingruby/tut_classes.html Ruby Classes]&amp;lt;/ref&amp;gt; methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock                   #BookInStock is a class name&lt;br /&gt;
    def initialize(isbn, price)       #initialize is used to initialize instance variables&lt;br /&gt;
       @isbn = isbn                   #@isbn and @price are instance variables&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book                     #self denotes class method&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title       #getter method&lt;br /&gt;
    attr_writer :price       #setter method&lt;br /&gt;
    attr_accessor : isbn     #getter and setter methods &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) #raise indicates exception&lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing&amp;lt;ref&amp;gt;[[8] http://rubylearning.com/satishtalim/duck_typing.html&amp;gt;&amp;lt;/ref&amp;gt;. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates &amp;gt;ref&amp;gt;[http://en.wikipedia.org/wiki/Duck_typing Duck typing]&amp;lt;/ref&amp;gt; in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.tutorialspoint.com/ruby/ruby_classes.htm]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Programming Ruby, The Pragmatic Programmer's Guide by Dave Thomas&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54218</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54218"/>
		<updated>2011-10-28T20:33:45Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Duck typing (Unbounded Polymorphism) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
In the following wiki, we will be covering the basics of closures and currying. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism). &lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures &amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt;help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas&amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/ proc and Lamda]&amp;lt;/ref&amp;gt;===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for the addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]                        #original addition function add&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry              #curried function curried_add &lt;br /&gt;
add_to_ten = curried_add[10]         #only 1 number specified to curried function curried_add, by fixing one of the input values&lt;br /&gt;
add_to_twenty = curried_add[20]      #thus the curried function always adds 10 and 20 to the second number when we use it with&lt;br /&gt;
                                     #add_to_ten  and add_to_twenty respectively&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]                   #adding second number 5 to the fixed value of 10&lt;br /&gt;
puts add_to_twenty[5]                #adding second number 5 to the fixed value of 20&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class&amp;lt;ref&amp;gt;[http://phrogz.net/programmingruby/tut_classes.html Ruby Classes]&amp;lt;/ref&amp;gt; methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock                   #BookInStock is a class name&lt;br /&gt;
    def initialize(isbn, price)       #initialize is used to initialize instance variables&lt;br /&gt;
       @isbn = isbn                   #@isbn and @price are instance variables&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book                     #self denotes class method&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title       #getter method&lt;br /&gt;
    attr_writer :price       #setter method&lt;br /&gt;
    attr_accessor : isbn     #getter and setter methods &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) #raise indicates exception&lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing&amp;lt;ref&amp;gt;[[8] http://rubylearning.com/satishtalim/duck_typing.html&amp;gt;&amp;lt;/ref&amp;gt;. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing]&amp;lt;/ref&amp;gt; in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Ira R. Forman and Nate Forman, ''Java Reflection in Action'' (2005), ISBN 1-932394-18-4&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54217</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54217"/>
		<updated>2011-10-28T20:32:38Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Duck typing (Unbounded Polymorphism) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
In the following wiki, we will be covering the basics of closures and currying. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism). &lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures &amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt;help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas&amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/ proc and Lamda]&amp;lt;/ref&amp;gt;===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for the addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]                        #original addition function add&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry              #curried function curried_add &lt;br /&gt;
add_to_ten = curried_add[10]         #only 1 number specified to curried function curried_add, by fixing one of the input values&lt;br /&gt;
add_to_twenty = curried_add[20]      #thus the curried function always adds 10 and 20 to the second number when we use it with&lt;br /&gt;
                                     #add_to_ten  and add_to_twenty respectively&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]                   #adding second number 5 to the fixed value of 10&lt;br /&gt;
puts add_to_twenty[5]                #adding second number 5 to the fixed value of 20&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class&amp;lt;ref&amp;gt;[http://phrogz.net/programmingruby/tut_classes.html Ruby Classes]&amp;lt;/ref&amp;gt; methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock                   #BookInStock is a class name&lt;br /&gt;
    def initialize(isbn, price)       #initialize is used to initialize instance variables&lt;br /&gt;
       @isbn = isbn                   #@isbn and @price are instance variables&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book                     #self denotes class method&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title       #getter method&lt;br /&gt;
    attr_writer :price       #setter method&lt;br /&gt;
    attr_accessor : isbn     #getter and setter methods &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) #raise indicates exception&lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing&amp;lt;ref&amp;gt;[[8] http://rubylearning.com/satishtalim/duck_typing.html&amp;gt;. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing] in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Ira R. Forman and Nate Forman, ''Java Reflection in Action'' (2005), ISBN 1-932394-18-4&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54214</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54214"/>
		<updated>2011-10-28T20:30:13Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Class */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
In the following wiki, we will be covering the basics of closures and currying. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism). &lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures &amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt;help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas&amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/ proc and Lamda]&amp;lt;/ref&amp;gt;===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for the addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]                        #original addition function add&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry              #curried function&lt;br /&gt;
add_to_ten = curried_add[10]         #only 1 number specified to curried function curried_add, fixing one of the input values&lt;br /&gt;
add_to_twenty = curried_add[20]      #thus the curried function always adds 10 and 20 to the second number when we use it with&lt;br /&gt;
                                     #add_to_ten  and add_to_twenty respectively&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]                   #adding second number 5 to the fixed value of 10&lt;br /&gt;
puts add_to_twenty[5]                #adding second number 5 to the fixed value of 20&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class&amp;lt;ref&amp;gt;[http://phrogz.net/programmingruby/tut_classes.html Ruby Classes]&amp;lt;/ref&amp;gt; methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock                   #BookInStock is a class name&lt;br /&gt;
    def initialize(isbn, price)       #initialize is used to initialize instance variables&lt;br /&gt;
       @isbn = isbn                   #@isbn and @price are instance variables&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book                     #self denotes class method&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title       #getter method&lt;br /&gt;
    attr_writer :price       #setter method&lt;br /&gt;
    attr_accessor : isbn     #getter and setter methods &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) #raise indicates exception&lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing] in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Ira R. Forman and Nate Forman, ''Java Reflection in Action'' (2005), ISBN 1-932394-18-4&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54212</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54212"/>
		<updated>2011-10-28T20:28:11Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Procs And Lambdas */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
In the following wiki, we will be covering the basics of closures and currying. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism). &lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures &amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt;help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas&amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/ proc and Lamda]&amp;lt;/ref&amp;gt;===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry&lt;br /&gt;
add_to_ten = curried_add[10]&lt;br /&gt;
add_to_twenty = curried_add[20]&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]&lt;br /&gt;
puts add_to_twenty[5]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock                   #BookInStock is a class name&lt;br /&gt;
    def initialize(isbn, price)       #initialize is used to initialize instance variables&lt;br /&gt;
       @isbn = isbn                   #@isbn and @price are instance variables&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book                     #self denotes class method&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title       #getter method&lt;br /&gt;
    attr_writer :price       #setter method&lt;br /&gt;
    attr_accessor : isbn     #getter and setter methods &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) #raise indicates exception&lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing] in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Ira R. Forman and Nate Forman, ''Java Reflection in Action'' (2005), ISBN 1-932394-18-4&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54211</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54211"/>
		<updated>2011-10-28T20:25:29Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Class */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
In the following wiki, we will be covering the basics of closures and currying. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism). &lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures &amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt;help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry&lt;br /&gt;
add_to_ten = curried_add[10]&lt;br /&gt;
add_to_twenty = curried_add[20]&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]&lt;br /&gt;
puts add_to_twenty[5]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock                   #BookInStock is a class name&lt;br /&gt;
    def initialize(isbn, price)       #initialize is used to initialize instance variables&lt;br /&gt;
       @isbn = isbn                   #@isbn and @price are instance variables&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book                     #self denotes class method&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title       #getter method&lt;br /&gt;
    attr_writer :price       #setter method&lt;br /&gt;
    attr_accessor : isbn     #getter and setter methods &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) #raise indicates exception&lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing] in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Ira R. Forman and Nate Forman, ''Java Reflection in Action'' (2005), ISBN 1-932394-18-4&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54210</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54210"/>
		<updated>2011-10-28T20:22:21Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Closures */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
In the following wiki, we will be covering the basics of closures and currying. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism). &lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures &amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt;help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry&lt;br /&gt;
add_to_ten = curried_add[10]&lt;br /&gt;
add_to_twenty = curried_add[20]&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]&lt;br /&gt;
puts add_to_twenty[5]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    def initialize(isbn, price)&lt;br /&gt;
       @isbn = isbn&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title&lt;br /&gt;
    attr_writer :price&lt;br /&gt;
    attr_accessor : isbn &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) &lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing] in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Ira R. Forman and Nate Forman, ''Java Reflection in Action'' (2005), ISBN 1-932394-18-4&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54209</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54209"/>
		<updated>2011-10-28T20:21:49Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Closures */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
In the following wiki, we will be covering the basics of closures and currying. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism). &lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined.&amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt;Closures help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry&lt;br /&gt;
add_to_ten = curried_add[10]&lt;br /&gt;
add_to_twenty = curried_add[20]&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]&lt;br /&gt;
puts add_to_twenty[5]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    def initialize(isbn, price)&lt;br /&gt;
       @isbn = isbn&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title&lt;br /&gt;
    attr_writer :price&lt;br /&gt;
    attr_accessor : isbn &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) &lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing] in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Ira R. Forman and Nate Forman, ''Java Reflection in Action'' (2005), ISBN 1-932394-18-4&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54208</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54208"/>
		<updated>2011-10-28T20:20:31Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Closures */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
In the following wiki, we will be covering the basics of closures and currying. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism). &lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. &amp;lt;ref&amp;gt;[http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/ Closures]&amp;lt;/ref&amp;gt; help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry&lt;br /&gt;
add_to_ten = curried_add[10]&lt;br /&gt;
add_to_twenty = curried_add[20]&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]&lt;br /&gt;
puts add_to_twenty[5]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    def initialize(isbn, price)&lt;br /&gt;
       @isbn = isbn&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title&lt;br /&gt;
    attr_writer :price&lt;br /&gt;
    attr_accessor : isbn &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) &lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing] in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=External links=&lt;br /&gt;
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]&lt;br /&gt;
&lt;br /&gt;
=Further reading=&lt;br /&gt;
* Ira R. Forman and Nate Forman, ''Java Reflection in Action'' (2005), ISBN 1-932394-18-4&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54206</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=54206"/>
		<updated>2011-10-28T20:18:49Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby. Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
In the following wiki, we will be covering the basics of closures and currying. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism). &lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry&lt;br /&gt;
add_to_ten = curried_add[10]&lt;br /&gt;
add_to_twenty = curried_add[20]&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]&lt;br /&gt;
puts add_to_twenty[5]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    def initialize(isbn, price)&lt;br /&gt;
       @isbn = isbn&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methods provide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title&lt;br /&gt;
    attr_writer :price&lt;br /&gt;
    attr_accessor : isbn &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) &lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing] in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53137</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53137"/>
		<updated>2011-10-20T18:42:54Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Duck typing (Unbounded Polymorphism) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
In the following wiki, we will be covering the basics of closures and currying. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism). &lt;br /&gt;
&lt;br /&gt;
Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry&lt;br /&gt;
add_to_ten = curried_add[10]&lt;br /&gt;
add_to_twenty = curried_add[20]&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]&lt;br /&gt;
puts add_to_twenty[5]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    def initialize(isbn, price)&lt;br /&gt;
       @isbn = isbn&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methodsprovide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title&lt;br /&gt;
    attr_writer :price&lt;br /&gt;
    attr_accessor : isbn &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) &lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing] in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new) # Frog is an animal&lt;br /&gt;
  t.test_animal(Dinosaur.new) # Dinosaur is an animal&lt;br /&gt;
  t.test_animal(Table.new) # Table is an animal!!&lt;br /&gt;
  t.test_animal(Bird.new) # Bird is not an animal&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] http://en.wikipedia.org/wiki/Closure_(computer_science)&lt;br /&gt;
&lt;br /&gt;
[2] http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/&lt;br /&gt;
&lt;br /&gt;
[3] http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/&lt;br /&gt;
&lt;br /&gt;
[4] http://phrogz.net/programmingruby/tut_classes.html&lt;br /&gt;
&lt;br /&gt;
[5] http://juixe.com/techknow/index.php/2007/01/22/ruby-class-tutorial/&lt;br /&gt;
&lt;br /&gt;
[6] http://www.tutorialspoint.com/ruby/ruby_classes.htm&lt;br /&gt;
&lt;br /&gt;
[7] Programming Ruby, The Pragmatic Programmer's Guide by Dave Thomas&lt;br /&gt;
&lt;br /&gt;
[8] http://rubylearning.com/satishtalim/duck_typing.html&lt;br /&gt;
&lt;br /&gt;
[9] http://devblog.famundo.com/articles/2007/01/12/ruby-duck-typing-goodness&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53134</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53134"/>
		<updated>2011-10-20T18:41:00Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Duck typing (Unbounded Polymorphism) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
In the following wiki, we will be covering the basics of closures and currying. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism). &lt;br /&gt;
&lt;br /&gt;
Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry&lt;br /&gt;
add_to_ten = curried_add[10]&lt;br /&gt;
add_to_twenty = curried_add[20]&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]&lt;br /&gt;
puts add_to_twenty[5]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    def initialize(isbn, price)&lt;br /&gt;
       @isbn = isbn&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methodsprovide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title&lt;br /&gt;
    attr_writer :price&lt;br /&gt;
    attr_accessor : isbn &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) &lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing] in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new)&lt;br /&gt;
  t.test_animal(Dinosaur.new)&lt;br /&gt;
  t.test_animal(Table.new)&lt;br /&gt;
  t.test_animal(Bird.new)&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use [http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing dynamic typing] are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] http://en.wikipedia.org/wiki/Closure_(computer_science)&lt;br /&gt;
&lt;br /&gt;
[2] http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/&lt;br /&gt;
&lt;br /&gt;
[3] http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/&lt;br /&gt;
&lt;br /&gt;
[4] http://phrogz.net/programmingruby/tut_classes.html&lt;br /&gt;
&lt;br /&gt;
[5] http://juixe.com/techknow/index.php/2007/01/22/ruby-class-tutorial/&lt;br /&gt;
&lt;br /&gt;
[6] http://www.tutorialspoint.com/ruby/ruby_classes.htm&lt;br /&gt;
&lt;br /&gt;
[7] Programming Ruby, The Pragmatic Programmer's Guide by Dave Thomas&lt;br /&gt;
&lt;br /&gt;
[8] http://rubylearning.com/satishtalim/duck_typing.html&lt;br /&gt;
&lt;br /&gt;
[9] http://devblog.famundo.com/articles/2007/01/12/ruby-duck-typing-goodness&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53133</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53133"/>
		<updated>2011-10-20T18:39:44Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Duck typing (Unbounded Polymorphism) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
In the following wiki, we will be covering the basics of closures and currying. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism). &lt;br /&gt;
&lt;br /&gt;
Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry&lt;br /&gt;
add_to_ten = curried_add[10]&lt;br /&gt;
add_to_twenty = curried_add[20]&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]&lt;br /&gt;
puts add_to_twenty[5]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    def initialize(isbn, price)&lt;br /&gt;
       @isbn = isbn&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methodsprovide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title&lt;br /&gt;
    attr_writer :price&lt;br /&gt;
    attr_accessor : isbn &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) &lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates [http://en.wikipedia.org/wiki/Duck_typing Duck typing] in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new)&lt;br /&gt;
  t.test_animal(Dinosaur.new)&lt;br /&gt;
  t.test_animal(Table.new)&lt;br /&gt;
  t.test_animal(Bird.new)&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use dynamic typing are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] http://en.wikipedia.org/wiki/Closure_(computer_science)&lt;br /&gt;
&lt;br /&gt;
[2] http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/&lt;br /&gt;
&lt;br /&gt;
[3] http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/&lt;br /&gt;
&lt;br /&gt;
[4] http://phrogz.net/programmingruby/tut_classes.html&lt;br /&gt;
&lt;br /&gt;
[5] http://juixe.com/techknow/index.php/2007/01/22/ruby-class-tutorial/&lt;br /&gt;
&lt;br /&gt;
[6] http://www.tutorialspoint.com/ruby/ruby_classes.htm&lt;br /&gt;
&lt;br /&gt;
[7] Programming Ruby, The Pragmatic Programmer's Guide by Dave Thomas&lt;br /&gt;
&lt;br /&gt;
[8] http://rubylearning.com/satishtalim/duck_typing.html&lt;br /&gt;
&lt;br /&gt;
[9] http://devblog.famundo.com/articles/2007/01/12/ruby-duck-typing-goodness&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53132</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53132"/>
		<updated>2011-10-20T18:38:59Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Class */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
In the following wiki, we will be covering the basics of closures and currying. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism). &lt;br /&gt;
&lt;br /&gt;
Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry&lt;br /&gt;
add_to_ten = curried_add[10]&lt;br /&gt;
add_to_twenty = curried_add[20]&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]&lt;br /&gt;
puts add_to_twenty[5]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide [http://en.wikipedia.org/wiki/Inheritance inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] and [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation], the three pillars. You can have class methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    def initialize(isbn, price)&lt;br /&gt;
       @isbn = isbn&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methodsprovide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title&lt;br /&gt;
    attr_writer :price&lt;br /&gt;
    attr_accessor : isbn &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) &lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates Duck typing in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new)&lt;br /&gt;
  t.test_animal(Dinosaur.new)&lt;br /&gt;
  t.test_animal(Table.new)&lt;br /&gt;
  t.test_animal(Bird.new)&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use dynamic typing are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] http://en.wikipedia.org/wiki/Closure_(computer_science)&lt;br /&gt;
&lt;br /&gt;
[2] http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/&lt;br /&gt;
&lt;br /&gt;
[3] http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/&lt;br /&gt;
&lt;br /&gt;
[4] http://phrogz.net/programmingruby/tut_classes.html&lt;br /&gt;
&lt;br /&gt;
[5] http://juixe.com/techknow/index.php/2007/01/22/ruby-class-tutorial/&lt;br /&gt;
&lt;br /&gt;
[6] http://www.tutorialspoint.com/ruby/ruby_classes.htm&lt;br /&gt;
&lt;br /&gt;
[7] Programming Ruby, The Pragmatic Programmer's Guide by Dave Thomas&lt;br /&gt;
&lt;br /&gt;
[8] http://rubylearning.com/satishtalim/duck_typing.html&lt;br /&gt;
&lt;br /&gt;
[9] http://devblog.famundo.com/articles/2007/01/12/ruby-duck-typing-goodness&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53128</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53128"/>
		<updated>2011-10-20T18:35:05Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
In the following wiki, we will be covering the basics of closures and currying. We will then go into the details of object-oriented concepts such as data encapsulation, inheritance and polymorphism. The wiki ends by covering the most popular feature in Ruby called duck typing (unbounded polymorphism). &lt;br /&gt;
&lt;br /&gt;
Since the lecture 5 material in the CSC517 covers object-oriented concepts specific to Ruby, thus we have restricted to the same.&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry&lt;br /&gt;
add_to_ten = curried_add[10]&lt;br /&gt;
add_to_twenty = curried_add[20]&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]&lt;br /&gt;
puts add_to_twenty[5]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide inheritance, polymorphism and encapsulation, the three pillars. You can have class methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    def initialize(isbn, price)&lt;br /&gt;
       @isbn = isbn&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methodsprovide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title&lt;br /&gt;
    attr_writer :price&lt;br /&gt;
    attr_accessor : isbn &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) &lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates Duck typing in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new)&lt;br /&gt;
  t.test_animal(Dinosaur.new)&lt;br /&gt;
  t.test_animal(Table.new)&lt;br /&gt;
  t.test_animal(Bird.new)&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use dynamic typing are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] http://en.wikipedia.org/wiki/Closure_(computer_science)&lt;br /&gt;
&lt;br /&gt;
[2] http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/&lt;br /&gt;
&lt;br /&gt;
[3] http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/&lt;br /&gt;
&lt;br /&gt;
[4] http://phrogz.net/programmingruby/tut_classes.html&lt;br /&gt;
&lt;br /&gt;
[5] http://juixe.com/techknow/index.php/2007/01/22/ruby-class-tutorial/&lt;br /&gt;
&lt;br /&gt;
[6] http://www.tutorialspoint.com/ruby/ruby_classes.htm&lt;br /&gt;
&lt;br /&gt;
[7] Programming Ruby, The Pragmatic Programmer's Guide by Dave Thomas&lt;br /&gt;
&lt;br /&gt;
[8] http://rubylearning.com/satishtalim/duck_typing.html&lt;br /&gt;
&lt;br /&gt;
[9] http://devblog.famundo.com/articles/2007/01/12/ruby-duck-typing-goodness&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53126</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53126"/>
		<updated>2011-10-20T18:20:03Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry&lt;br /&gt;
add_to_ten = curried_add[10]&lt;br /&gt;
add_to_twenty = curried_add[20]&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]&lt;br /&gt;
puts add_to_twenty[5]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide inheritance, polymorphism and encapsulation, the three pillars. You can have class methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    def initialize(isbn, price)&lt;br /&gt;
       @isbn = isbn&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methodsprovide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title&lt;br /&gt;
    attr_writer :price&lt;br /&gt;
    attr_accessor : isbn &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) &lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates Duck typing in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new)&lt;br /&gt;
  t.test_animal(Dinosaur.new)&lt;br /&gt;
  t.test_animal(Table.new)&lt;br /&gt;
  t.test_animal(Bird.new)&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use dynamic typing are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that the developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] http://en.wikipedia.org/wiki/Closure_(computer_science)&lt;br /&gt;
&lt;br /&gt;
[2] http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/&lt;br /&gt;
&lt;br /&gt;
[3] http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/&lt;br /&gt;
&lt;br /&gt;
[4] http://phrogz.net/programmingruby/tut_classes.html&lt;br /&gt;
&lt;br /&gt;
[5] http://juixe.com/techknow/index.php/2007/01/22/ruby-class-tutorial/&lt;br /&gt;
&lt;br /&gt;
[6] http://www.tutorialspoint.com/ruby/ruby_classes.htm&lt;br /&gt;
&lt;br /&gt;
[7] Programming Ruby, The Pragmatic Programmer's Guide by Dave Thomas&lt;br /&gt;
&lt;br /&gt;
[8] http://rubylearning.com/satishtalim/duck_typing.html&lt;br /&gt;
&lt;br /&gt;
[9] http://devblog.famundo.com/articles/2007/01/12/ruby-duck-typing-goodness&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53123</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53123"/>
		<updated>2011-10-20T18:16:24Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Conclusion */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry&lt;br /&gt;
add_to_ten = curried_add[10]&lt;br /&gt;
add_to_twenty = curried_add[20]&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]&lt;br /&gt;
puts add_to_twenty[5]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide inheritance, polymorphism and encapsulation, the three pillars. You can have class methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    def initialize(isbn, price)&lt;br /&gt;
       @isbn = isbn&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methodsprovide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title&lt;br /&gt;
    attr_writer :price&lt;br /&gt;
    attr_accessor : isbn &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) &lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates Duck typing in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new)&lt;br /&gt;
  t.test_animal(Dinosaur.new)&lt;br /&gt;
  t.test_animal(Table.new)&lt;br /&gt;
  t.test_animal(Bird.new)&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use dynamic typing are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes which are basic elements in object-oriented programming and duck typing which is very popular in Ruby and used most often. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation, code reuse via inheritance and polymorphism. Ultimately we believe that developer has to weigh the options available according to the requirements of the application and use the Ruby features accordingly.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] http://en.wikipedia.org/wiki/Closure_(computer_science)&lt;br /&gt;
&lt;br /&gt;
[2] http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/&lt;br /&gt;
&lt;br /&gt;
[3] http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53120</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53120"/>
		<updated>2011-10-20T18:11:16Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry&lt;br /&gt;
add_to_ten = curried_add[10]&lt;br /&gt;
add_to_twenty = curried_add[20]&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]&lt;br /&gt;
puts add_to_twenty[5]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide inheritance, polymorphism and encapsulation, the three pillars. You can have class methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    def initialize(isbn, price)&lt;br /&gt;
       @isbn = isbn&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methodsprovide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title&lt;br /&gt;
    attr_writer :price&lt;br /&gt;
    attr_accessor : isbn &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. There are three levels of protection provided by Ruby,&lt;br /&gt;
&lt;br /&gt;
1. Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default (   except initialize, which is private).&lt;br /&gt;
2. Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3. Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control. One can just choose any relevant access specifier before each method is defined as shown here.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
       raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) &lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
       puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However as mentioned earlier Ruby programmers use abstract methods very rarely.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates Duck typing in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new)&lt;br /&gt;
  t.test_animal(Dinosaur.new)&lt;br /&gt;
  t.test_animal(Table.new)&lt;br /&gt;
  t.test_animal(Bird.new)&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use dynamic typing are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by explaining what closures are and in Ruby how this can be achieved using block and procs. Then we explained classes and duck typing in Ruby. Closures allow a programmer to write shorter code, while classes in Ruby provide data encapsulation and extension of code . Ultimately it is the developer who chooses when to use closures and classes based on the needs of his application.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] http://en.wikipedia.org/wiki/Closure_(computer_science)&lt;br /&gt;
&lt;br /&gt;
[2] http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/&lt;br /&gt;
&lt;br /&gt;
[3] http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53116</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53116"/>
		<updated>2011-10-20T18:04:54Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby].&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to one's needs. Consider the following example where we have a Proc for addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry&lt;br /&gt;
add_to_ten = curried_add[10]&lt;br /&gt;
add_to_twenty = curried_add[20]&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]&lt;br /&gt;
puts add_to_twenty[5]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
A class is the blueprint from which individual objects are created.  In object-oriented programming classes are the basic elements which provide inheritance, polymorphism and encapsulation, the three pillars. You can have class methods and instance methods. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is the example for a class BookInStock. &lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    def initialize(isbn, price)&lt;br /&gt;
       @isbn = isbn&lt;br /&gt;
       @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    def self.book&lt;br /&gt;
        puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
Here, initialize is a special method in Ruby. When you call BookInStock.new to create a new BookInStock object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state. This is very similar to constructors in Java. Then there is self.book which is class method which is very similar to static methods in Java. The variables starting with @ are instance variables meaning that they are associated with the instances. In the next few sections we will take a look at the attributes, access control mechanisms and inheritance features provided in the class.&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors. Ruby defines three accessor methods attr_reader, attr_writer and attr_accessor. &lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. &lt;br /&gt;
&lt;br /&gt;
These methodsprovide access to the underlying instance variables of the name (with a leading @sign). The below example illustrates the use of these methods. &lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title&lt;br /&gt;
    attr_writer :price&lt;br /&gt;
    attr_accessor : isbn &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
These methods will have the same effect as shown in the below table.&lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  #outputs blurp, blurp&lt;br /&gt;
  beverage.intake #outputs Sweet, tasty tasty&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. &lt;br /&gt;
&lt;br /&gt;
There are three levels of protection provided by Ruby:&lt;br /&gt;
&lt;br /&gt;
1.	Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default ( except initialize, which is private).&lt;br /&gt;
2.	Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3.	Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
           raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) &lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
           puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However the notion of abstract methods in the Ruby are not used heavily.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates Duck typing in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new)&lt;br /&gt;
  t.test_animal(Dinosaur.new)&lt;br /&gt;
  t.test_animal(Table.new)&lt;br /&gt;
  t.test_animal(Bird.new)&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use dynamic typing are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
We started by listing out the collections present in Java which uses JCF, and C++ which uses STL. Then we made a comparison of the collections in C++ , Java and Ruby. Each language's implementation of collections has its pros and cons. Ultimately it is the developer who chooses which one to use, and this is based on the needs of his application. In general C++ STL provides collections that are fast, Java JCF provides collections that are safe, while in Ruby, the collections can be written with minimal code as they are built into the language.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] http://en.wikipedia.org/wiki/Closure_(computer_science)&lt;br /&gt;
&lt;br /&gt;
[2] http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/&lt;br /&gt;
&lt;br /&gt;
[3] http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53100</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53100"/>
		<updated>2011-10-20T17:44:00Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A closure may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in Ruby.&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method &amp;lt;nowiki&amp;gt;&amp;lt;nowiki&amp;gt;Insert non-formatted text here&amp;lt;/nowiki&amp;gt;&amp;lt;nowiki&amp;gt;&amp;lt;nowiki&amp;gt;Insert non-formatted text here&amp;lt;/nowiki&amp;gt;&amp;lt;/nowiki&amp;gt;&amp;lt;/nowiki&amp;gt;is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to ones needs. Consider the following example where we have a Proc for addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry&lt;br /&gt;
add_to_ten = curried_add[10]&lt;br /&gt;
add_to_twenty = curried_add[20]&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]&lt;br /&gt;
puts add_to_twenty[5]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
Classes are templates for creating object instances. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is a quick example and then we’ll go into a bit more detail.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    def initialize(isbn, price)&lt;br /&gt;
         @isbn = isbn&lt;br /&gt;
         @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    delf self.book&lt;br /&gt;
       puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
initialize is a special method in Ruby programs. When you call Song.new to create a new Song object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Attributes===&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors.&lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance&lt;br /&gt;
variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. These methods&lt;br /&gt;
provide access to the underlying instance variables of the name name (with a leading @&lt;br /&gt;
sign).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title&lt;br /&gt;
    attr_writer :price&lt;br /&gt;
    attr_accessor : isbn &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
===Inheritance===&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  &lt;br /&gt;
  beverage.intake&lt;br /&gt;
&lt;br /&gt;
===Access control===&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. &lt;br /&gt;
&lt;br /&gt;
There are three levels of protection provided by Ruby:&lt;br /&gt;
&lt;br /&gt;
1.	Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default ( except initialize, which is private).&lt;br /&gt;
2.	Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3.	Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
===Abstract methods===&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
           raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) &lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
           puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However the notion of abstract methods in the Ruby are not used heavily.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates Duck typing in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new)&lt;br /&gt;
  t.test_animal(Dinosaur.new)&lt;br /&gt;
  t.test_animal(Table.new)&lt;br /&gt;
  t.test_animal(Bird.new)&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may prove increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use dynamic typing are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] http://en.wikipedia.org/wiki/Closure_(computer_science)&lt;br /&gt;
&lt;br /&gt;
[2] http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/&lt;br /&gt;
&lt;br /&gt;
[3] http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53098</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53098"/>
		<updated>2011-10-20T17:41:52Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A closure may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in Ruby.&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method &amp;lt;nowiki&amp;gt;&amp;lt;nowiki&amp;gt;Insert non-formatted text here&amp;lt;/nowiki&amp;gt;&amp;lt;nowiki&amp;gt;&amp;lt;nowiki&amp;gt;Insert non-formatted text here&amp;lt;/nowiki&amp;gt;&amp;lt;/nowiki&amp;gt;&amp;lt;/nowiki&amp;gt;is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to ones needs. Consider the following example where we have a Proc for addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry&lt;br /&gt;
add_to_ten = curried_add[10]&lt;br /&gt;
add_to_twenty = curried_add[20]&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]&lt;br /&gt;
puts add_to_twenty[5]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
Classes are templates for creating object instances. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is a quick example and then we’ll go into a bit more detail.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    def initialize(isbn, price)&lt;br /&gt;
         @isbn = isbn&lt;br /&gt;
         @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    delf self.book&lt;br /&gt;
       puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
initialize is a special method in Ruby programs. When you call Song.new to create a new Song object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Attributes==&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors.&lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance&lt;br /&gt;
variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. These methods&lt;br /&gt;
provide access to the underlying instance variables of the name name (with a leading @&lt;br /&gt;
sign).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title&lt;br /&gt;
    attr_writer :price&lt;br /&gt;
    attr_accessor : isbn &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
==Inheritance==&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  &lt;br /&gt;
  beverage.intake&lt;br /&gt;
&lt;br /&gt;
==Access control==&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. &lt;br /&gt;
&lt;br /&gt;
There are three levels of protection provided by Ruby:&lt;br /&gt;
&lt;br /&gt;
1.	Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default ( except initialize, which is private).&lt;br /&gt;
2.	Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3.	Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
==Abstract methods==&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
           raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) &lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
           puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However the notion of abstract methods in the Ruby are not used heavily.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates Duck typing in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
    def chirp&lt;br /&gt;
      puts “kuckoo”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new)&lt;br /&gt;
  t.test_animal(Dinosaur.new)&lt;br /&gt;
  t.test_animal(Table.new)&lt;br /&gt;
  t.test_animal(Bird.new)&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may prove increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use dynamic typing are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] http://en.wikipedia.org/wiki/Closure_(computer_science)&lt;br /&gt;
&lt;br /&gt;
[2] http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/&lt;br /&gt;
&lt;br /&gt;
[3] http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53096</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53096"/>
		<updated>2011-10-20T17:41:01Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A closure may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in Ruby.&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method &amp;lt;nowiki&amp;gt;&amp;lt;nowiki&amp;gt;Insert non-formatted text here&amp;lt;/nowiki&amp;gt;&amp;lt;nowiki&amp;gt;&amp;lt;nowiki&amp;gt;Insert non-formatted text here&amp;lt;/nowiki&amp;gt;&amp;lt;/nowiki&amp;gt;&amp;lt;/nowiki&amp;gt;is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to ones needs. Consider the following example where we have a Proc for addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry&lt;br /&gt;
add_to_ten = curried_add[10]&lt;br /&gt;
add_to_twenty = curried_add[20]&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]&lt;br /&gt;
puts add_to_twenty[5]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
Classes are templates for creating object instances. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is a quick example and then we’ll go into a bit more detail.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    def initialize(isbn, price)&lt;br /&gt;
         @isbn = isbn&lt;br /&gt;
         @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    delf self.book&lt;br /&gt;
       puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
initialize is a special method in Ruby programs. When you call Song.new to create a new Song object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Attributes==&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors.&lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance&lt;br /&gt;
variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. These methods&lt;br /&gt;
provide access to the underlying instance variables of the name name (with a leading @&lt;br /&gt;
sign).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title&lt;br /&gt;
    attr_writer :price&lt;br /&gt;
    attr_accessor : isbn &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
==Inheritance==&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  &lt;br /&gt;
  beverage.intake&lt;br /&gt;
&lt;br /&gt;
==Access control==&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. &lt;br /&gt;
&lt;br /&gt;
There are three levels of protection provided by Ruby:&lt;br /&gt;
&lt;br /&gt;
1.	Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default ( except initialize, which is private).&lt;br /&gt;
2.	Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3.	Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
==Abstract methods==&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
    def talk	&lt;br /&gt;
           raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) &lt;br /&gt;
    end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
    def talk&lt;br /&gt;
           puts “Roar! Roar”&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However the notion of abstract methods in the Ruby are not used heavily.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates Duck typing in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
   def chirp&lt;br /&gt;
	puts “kuckoo”&lt;br /&gt;
   end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new)&lt;br /&gt;
  t.test_animal(Dinosaur.new)&lt;br /&gt;
  t.test_animal(Table.new)&lt;br /&gt;
  t.test_animal(Bird.new)&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may prove increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use dynamic typing are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] http://en.wikipedia.org/wiki/Closure_(computer_science)&lt;br /&gt;
&lt;br /&gt;
[2] http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/&lt;br /&gt;
&lt;br /&gt;
[3] http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53095</id>
		<title>CSC/ECE 517 Fall 2011/ch4 4b ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch4_4b_ds&amp;diff=53095"/>
		<updated>2011-10-20T17:39:13Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wiki textbook chapter on OOLS Lecture 5. Covers the basic of closures and blocks, currying and OOP in Ruby.&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
==Closures==&lt;br /&gt;
A closure is a block of code that “closes over”. This means it can access the lexical environment of its definition. A closure may be defined in one scope and get called outside this scope. Thus a closure  retains the values of all the variables that were in scope when the closure was defined. Closures help in making the code short such that one can do more with less code. Ruby supports closures through Blocks and Procs.&lt;br /&gt;
&lt;br /&gt;
===Blocks===&lt;br /&gt;
A block is a set of Ruby statements either between braces or a do/end pair, and appear only immediately after a method invocation. Ruby uses the following standard - braces for single-line blocks and do/end for multiline blocks.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
{ puts &amp;quot;Hello World&amp;quot; }                # braces block&lt;br /&gt;
&lt;br /&gt;
do&lt;br /&gt;
{ puts &amp;quot;Hello World 1&amp;quot; }              # do/end block&lt;br /&gt;
{ puts &amp;quot;Hello World 2&amp;quot; }&lt;br /&gt;
{ puts &amp;quot;Hello World 3&amp;quot; }&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Blocks can be instantiated as a Proc object using the Proc or lambda method. The block is then bound to a set of local variables. Once bound, the block code may be called in different contexts through these set variables.Using the example mentioned in lecture 5 in class.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# Class to generate adders&lt;br /&gt;
class AdderGen&lt;br /&gt;
  def initialize(n)&lt;br /&gt;
	@block = lambda {|a| n + a}&lt;br /&gt;
  end&lt;br /&gt;
 &lt;br /&gt;
  def add(a)&lt;br /&gt;
	@block.call a&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
twoAdder = AdderGen.new 2&lt;br /&gt;
incrementer = AdderGen.new 1&lt;br /&gt;
puts incrementer.add(4)&lt;br /&gt;
puts twoAdder.add(6)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
5&lt;br /&gt;
8&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
@block is the Ruby closure that gets initialized when the lambda method gets called through the class initialize method. The block remembers the parameter with which the initialize method was called even after the initialize method exits. This value of the block  is used during the add method invocation.&lt;br /&gt;
&lt;br /&gt;
===Procs And Lambdas===&lt;br /&gt;
There are three ways to create a Proc object in Ruby.&lt;br /&gt;
&lt;br /&gt;
====Proc.new====&lt;br /&gt;
Proc.new takes in a block and returns a Proc object which will run the code in the block when call method &amp;lt;nowiki&amp;gt;&amp;lt;nowiki&amp;gt;Insert non-formatted text here&amp;lt;/nowiki&amp;gt;&amp;lt;nowiki&amp;gt;&amp;lt;nowiki&amp;gt;Insert non-formatted text here&amp;lt;/nowiki&amp;gt;&amp;lt;/nowiki&amp;gt;&amp;lt;/nowiki&amp;gt;is invoked.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = Proc.new {puts &amp;quot;Create Proc.new object&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Proc method====&lt;br /&gt;
The proc method is equivalent to Proc.new in Ruby 1.9, but in Ruby 1.8 it is equivalent to lambda. &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = proc {puts &amp;quot;Create proc from Proc method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Lambda method====&lt;br /&gt;
This creates a  proc object using the lambda method&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
proc_object = lambda {puts &amp;quot;Create proc from Lambda method&amp;quot;}&lt;br /&gt;
proc_object.call&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Currying==&lt;br /&gt;
Currying is the concept of creating a new function out of an existing function by fixing the value of some of its input parameters.  Currying thus makes a generic function more specific to ones needs. Consider the following example where we have a Proc for addition of two numbers. Using currying we can fix the value of the first argument so that when the curried function is called later on with only one argument, it can use the earlier fixed value as the other argument for its addition. Ruby 1.9 allows the creation of a curry-able proc by calling the curry method on it.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
add = lambda {|a,b| a + b}&lt;br /&gt;
puts add[1,2]&lt;br /&gt;
&lt;br /&gt;
curried_add = add.curry&lt;br /&gt;
add_to_ten = curried_add[10]&lt;br /&gt;
add_to_twenty = curried_add[20]&lt;br /&gt;
&lt;br /&gt;
puts add_to_ten[5]&lt;br /&gt;
puts add_to_twenty[5]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Output&lt;br /&gt;
3&lt;br /&gt;
15&lt;br /&gt;
25&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Class==&lt;br /&gt;
Classes are templates for creating object instances. Class methods are methods that are called on a class and instance methods are methods that are called on an instance of a class. Here is a quick example and then we’ll go into a bit more detail.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    def initialize(isbn, price)&lt;br /&gt;
         @isbn = isbn&lt;br /&gt;
         @price = Float(price)&lt;br /&gt;
    end&lt;br /&gt;
    delf self.book&lt;br /&gt;
       puts “Class method”&lt;br /&gt;
    end&lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
initialize is a special method in Ruby programs. When you call Song.new to create a new Song object, Ruby creates an uninitialized object and then calls that object's initialize method, passing in any parameters that were passed to new. This gives you a chance to write code that sets up your object's state.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Attributes==&lt;br /&gt;
An object's instance variables are its attributes, the things that distinguish it from other objects of the same class. It is important to be able to write and read these attributes; doing so requires methods called attribute accessors.&lt;br /&gt;
&lt;br /&gt;
Attr_reader: Creates instance variables and corresponding methods that return the value of each instance&lt;br /&gt;
variable.&lt;br /&gt;
&lt;br /&gt;
Attr_writer: Creates an accessor method to allow assignment to the attribute&lt;br /&gt;
&lt;br /&gt;
Attr_accessor: Creates a reader and a writer method for each symbol passed as an argument. These methods&lt;br /&gt;
provide access to the underlying instance variables of the name name (with a leading @&lt;br /&gt;
sign).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class BookInStock&lt;br /&gt;
    attr_reader :title&lt;br /&gt;
    attr_writer :price&lt;br /&gt;
    attr_accessor : isbn &lt;br /&gt;
  end &lt;br /&gt;
&lt;br /&gt;
  Shortcut	         Effect&lt;br /&gt;
  attr_reader :title	 def title; @title; end&lt;br /&gt;
  attr_writer :price	 def price=(price); @price=price; end&lt;br /&gt;
  attr_accessor :isbn	 attr_reader :isbn; attr_writer :isbn&lt;br /&gt;
&lt;br /&gt;
==Inheritance==&lt;br /&gt;
&lt;br /&gt;
Inheritance is one of the pillars of object-oriented programming. Inheritance allows you to create a class that is a refinement or specialization of another class. This class is called a subclass of the original, and the original is a superclass of the subclass. &lt;br /&gt;
&lt;br /&gt;
For example here Ale is-a subclass of Beer and Beer is-a superclass of Ale. Inheritance allows a subclass to have all the methods defined in the superclass and hence promotes code reuse.  In addition subclass can override the methods which are much more specialized than superclass.  Ale class now gets the intake method defined in the Beer and also it has another method defined taste which varies from one subclass to another. Also it’s important to note that all classes in Ruby inherit from the Object class and hence all the methods declared in the Object class are now implicitly part of any class we declare.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Beer  &lt;br /&gt;
    def intake  &lt;br /&gt;
      puts &amp;quot;blurp blurp&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  class Ale &amp;lt; Beer  &lt;br /&gt;
    def taste &lt;br /&gt;
      puts &amp;quot;Sweet, tasty tasty&amp;quot;  &lt;br /&gt;
    end  &lt;br /&gt;
  end  &lt;br /&gt;
 &lt;br /&gt;
  beverage = Ale.new  &lt;br /&gt;
  beverage.taste  &lt;br /&gt;
  beverage.intake&lt;br /&gt;
&lt;br /&gt;
==Access control==&lt;br /&gt;
&lt;br /&gt;
Ruby allows having control over the methods defined in the class. &lt;br /&gt;
&lt;br /&gt;
There are three levels of protection provided by Ruby:&lt;br /&gt;
&lt;br /&gt;
1.	Public methods can be called by any class. No access control is enforced. In Ruby, methods are public by default ( except initialize, which is private).&lt;br /&gt;
2.	Protected methods can be used by the class which defines them and the subclass which inherit these classes.&lt;br /&gt;
3.	Private methods can be called only in the context of the current object. You can’t invoke other objects private methods. &lt;br /&gt;
&lt;br /&gt;
The below example shows some details about access control.&lt;br /&gt;
  class AccessControlExample&lt;br /&gt;
   def method1 # default is “public” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   protected # subsequent methods will be “protected” &lt;br /&gt;
   def method2 # will be “protected” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
   private # subsequent methods will be “private” &lt;br /&gt;
   def method3 # will be “private” &lt;br /&gt;
     #... &lt;br /&gt;
   end &lt;br /&gt;
   public # subsequent methods will be “public” &lt;br /&gt;
   def method4 # and this will be “public” &lt;br /&gt;
    #... &lt;br /&gt;
   end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
==Abstract methods==&lt;br /&gt;
&lt;br /&gt;
Ruby doesn’t support the concept of abstract methods. This is because Ruby is dynamically typed and you can add methods on the fly. If you want to simulate the notion of abstract method, you can do the following,&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Animal&lt;br /&gt;
	def talk	&lt;br /&gt;
           raise “NotImplementedError.new(&amp;quot;Method not implemented&amp;quot;) &lt;br /&gt;
 	end &lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur &amp;lt; Animal&lt;br /&gt;
	def talk&lt;br /&gt;
		puts “Roar! Roar”&lt;br /&gt;
	end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
Here Dinosaur class implements talk method. If you don’t implement the talk method in Dinosaur, an attempt to instantiate the class throws an error. However the notion of abstract methods in the Ruby are not used heavily.&lt;br /&gt;
&lt;br /&gt;
==Duck typing (Unbounded Polymorphism)==&lt;br /&gt;
&lt;br /&gt;
In Ruby, the class is never the type. Instead, the type of an object is defined more by what that object can do which is determined by the methods and properties rather than inheritance from particular class. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck. &lt;br /&gt;
&lt;br /&gt;
Lets look at the example below. &lt;br /&gt;
&lt;br /&gt;
There are 4 classes defined which are not related in any way. The classes Frog, Dinosaur, Table have a talk method defined while the class Bird has chirp method defined. Since the Table class has a talk method we can say it has animal even though by reality it does not belong which illustrates Duck typing in Ruby. Since Bird class does not implement the talk method it is not classified as of type animal. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  class Frog&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;ribbit, ribbit&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Dinosaur&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;Roar&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Table&lt;br /&gt;
    def talk&lt;br /&gt;
         puts &amp;quot;chss, chss&amp;quot;&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Bird&lt;br /&gt;
   def chirp&lt;br /&gt;
	puts “kuckoo”&lt;br /&gt;
   end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  class Test&lt;br /&gt;
    def test_animal(an)&lt;br /&gt;
         an.talk&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  t = Test.new&lt;br /&gt;
  t.test_animal(Frog.new)&lt;br /&gt;
  t.test_animal(Dinosaur.new)&lt;br /&gt;
  t.test_animal(Table.new)&lt;br /&gt;
  t.test_animal(Bird.new)&lt;br /&gt;
&lt;br /&gt;
The downside of duck typing is that, the absence of the static type checking may prove increase the execution time. This is also dynamic typing because type information is determined at run-time. Other well-known languages which heavily use dynamic typing are Python, PHP, Perl, Objective-C, etc.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] http://en.wikipedia.org/wiki/Closure_(computer_science)&lt;br /&gt;
&lt;br /&gt;
[2] http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/&lt;br /&gt;
&lt;br /&gt;
[3] http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=51617</id>
		<title>CSC/ECE 517 Fall 2011/ch2 2c ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=51617"/>
		<updated>2011-09-30T23:48:05Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Mixins vs. Interfaces=&lt;br /&gt;
&lt;br /&gt;
=Introduction=&lt;br /&gt;
&lt;br /&gt;
In object oriented programming languages, Mixins and Interfaces provide neat constructs to implement certain functionality and benefit from code re-usability. Understanding these constructs will benefit any programmer in designing any software with maximum polymorphic behavior and code re-usability. &lt;br /&gt;
&lt;br /&gt;
With the advent of object oriented languages, the designers of the language had to come up with the decision of whether or not to include the concept of multiple inheritance. Languages like C++ and Perl allow multiple inheritance whereas the designers of languages like C# and Java decided not to because of the problems associated with multiple inheritance&amp;lt;ref&amp;gt;[http://www.artima.com/intv/gosling13.html Inspiration for Interface]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
While [http://en.wikipedia.org/wiki/Java_%28programming_language%29 Java] like languages implemented interfaces to allow for [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism],languages like [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] opted not to implement multiple inheritance but to allow the code from one module be added into another class. &lt;br /&gt;
&lt;br /&gt;
Though both interfaces and Mixins simulate multiple inheritance and avoid the common pathologies associated with it , they have their own set of compromises. The below article tries to provide clarity on how this is achieved in each and also provides other distinctive features of Mixins and interfaces. &lt;br /&gt;
&lt;br /&gt;
===Interfaces===&lt;br /&gt;
In an object-oriented programming languages such as Java, C#, an interface&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/ Interfaces] &amp;lt;/ref&amp;gt; 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. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
&lt;br /&gt;
  public interface ParkingLot {&lt;br /&gt;
        boolean add(Car car, int slot);&lt;br /&gt;
        boolean remove(Car car);&lt;br /&gt;
        boolean findCar(Int number);&lt;br /&gt;
        int freeSlotsCount();&lt;br /&gt;
        int occupiedSlots();&lt;br /&gt;
        int parkingType();&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration);&lt;br /&gt;
        int findParkingSlot();&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
  public class Mall implements ParkingLot {&lt;br /&gt;
        boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }&lt;br /&gt;
        boolean remove(Car car){ // do something }&lt;br /&gt;
        boolean findCar(Int number){ // do something }&lt;br /&gt;
        int freeSlotsCount(){ // do something }&lt;br /&gt;
        int occupiedSlots(){ // do something }&lt;br /&gt;
        int parkingType(){ // do something }&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration){ // do something }&lt;br /&gt;
        int findParkingSlot(){ // do something }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
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. Interfaces provide an alternative  for languages like Java that does not allow multiple inheritance .&lt;br /&gt;
&lt;br /&gt;
In Java, a class can inherit from only one class but it can implement more than one interface. Therefore, objects can have multiple types: the type of their own class and the types of all the interfaces that they implement. This means that if a variable is declared to be the type of an interface, its value can reference any object that is instantiated from any class that implements the interface.&lt;br /&gt;
&lt;br /&gt;
==Mixins==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Modules are defined in Ruby using the ''module'' keyword.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;ref&amp;gt;[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Below is an example for modules and Mixins:&lt;br /&gt;
&lt;br /&gt;
The module ParkingSlot consists of the methods park and unpark&lt;br /&gt;
  &amp;lt;span style=&amp;quot;color:#4682B4&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingSlot&lt;br /&gt;
        def park&lt;br /&gt;
           #code to park the car&lt;br /&gt;
        end&lt;br /&gt;
        def unpark&lt;br /&gt;
           #code to unpark the car&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/span&amp;gt;&lt;br /&gt;
The module ParkingMeter consists of the methods calculate and printreceipt&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#F4A460&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingMeter&lt;br /&gt;
        def calculate&lt;br /&gt;
           #code to calculate the parking fee&lt;br /&gt;
        end&lt;br /&gt;
        def printreceipt&lt;br /&gt;
           #code to print the receipt&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
When a class ''includes'' a module via include Module Name, all the methods on that module become instance methods on the class.&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#6B8E23&amp;quot;&amp;gt;&lt;br /&gt;
  class Parking&lt;br /&gt;
       include ParkingSlot&lt;br /&gt;
       include ParkingMeter&lt;br /&gt;
       def printcardetails&lt;br /&gt;
           #code to print the details and type of car&lt;br /&gt;
       end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
  p=Parking.new   &lt;br /&gt;
  p.park            # -&amp;gt; Method park from module ParkingSlot&lt;br /&gt;
  p.unpark          # -&amp;gt; Method unpark from module ParkingSlot&lt;br /&gt;
  p.calculate       # -&amp;gt; Method calculate from module ParkingMeter&lt;br /&gt;
  p.printreceipt    # -&amp;gt; Method printreceipt from module ParkingMeter&lt;br /&gt;
  p.printcardetails # -&amp;gt; Calls printCarDetails from class&lt;br /&gt;
&lt;br /&gt;
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''.&lt;br /&gt;
&lt;br /&gt;
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 [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Subclasses_and_superclasses superclass].&lt;br /&gt;
&lt;br /&gt;
[[Image:ParkingLot.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
==Supported Languages==&lt;br /&gt;
The following table shows support for Mixins and Interfaces by most commonly used languages.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Languages&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| Ruby&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Java&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Python&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Smalltalk&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Perl&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| C#&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=Multiple Inheritance=&lt;br /&gt;
[http://en.wikipedia.org/wiki/Multiple_inheritance Multiple Inheritance] refers to a feature in some [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented programming] languages in which a class can inherit behaviors from more than one superclass. This contrasts with single inheritance in which a class can inherit behavior from at most one superclass. &lt;br /&gt;
Though Multiple Inheritance provides its own advantages of improved modularity and ease of reuse of code in certain applications, it has its own set of disadvantages which sometimes outweigh the possible advantages.&lt;br /&gt;
&lt;br /&gt;
==Diamond Problem==&lt;br /&gt;
This section describes the well know “Diamond Problem”&amp;lt;ref&amp;gt;[http://www.artima.com/designtechniques/interfaces2.html Diamond Problem] &amp;lt;/ref&amp;gt; associated with multiple Inheritance and the succeeding sections describe how Mixins and interfaces can be used to overcome this problem.&lt;br /&gt;
The diamond problem is the ambiguity that can occur when a class inherits from two different classes that both descend from a common superclass. For example, consider a scenario where one decides to combine the Frog and Dinosaur species which both are inherited from the Animal class. The talk() method in the Animal class is abstract and both Frog and Dinosaur needs to implement this method.&lt;br /&gt;
&lt;br /&gt;
Lets say both Frog and Dinosaur implement the talk method like this:&lt;br /&gt;
&lt;br /&gt;
    public class Frog extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Frog, I can croak “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
and,&lt;br /&gt;
    public class Dinosaur extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Dinosaur, I can roar “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
[[Image:Diamond_problem.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
When the Frogsaur is created, it inherits from both Frog and Dinosaur. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    public class Frogsaur extends Frog, Dinosaur {&lt;br /&gt;
       // Note below syntax is used just for demonstration. However java might throw compile time error.&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
The real problem occurs when someone tries to invoke talk() method on a Frogsaur object from the Animal reference.&lt;br /&gt;
    &lt;br /&gt;
    Animal species = new Frogsaur();&lt;br /&gt;
    species.talk(); // which method to invoke ???&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Due to the ambiguity caused by the diamond problem, it isn’t clear whether the runtime system should invoke Frog’s talk() method or Dinosaur talk() method.&lt;br /&gt;
&lt;br /&gt;
==Approaches==&lt;br /&gt;
Different programming languages have addressed the diamond problem in different ways.&lt;br /&gt;
&lt;br /&gt;
In Java, interfaces solve all these ambiguities caused by the diamond problem. Through interfaces, Java allows multiple inheritance of interface but not of implementation. Implementation, which includes instance variables and method implementations, is always singly inherited. As a result, confusion will never arise in Java over which inherited instance variable or method implementation to use.&lt;br /&gt;
&lt;br /&gt;
Ruby does not support multiple inheritance. Mixin provide a way which eliminates the need for multiple inheritance. Ruby has modules which are just like abstract classes&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/java/IandI/abstract.html Abstract Classes]&amp;lt;/ref&amp;gt; in Java. Modules can have different methods implemented in them. They cannot be instantiated like abstract classes. They cannot inherit from other modules or classes. Ruby classes can inherit from only one superclass but can have unlimited number of modules in them to exploit the usage of predefined implementations in these modules. This provides functionality similar to multiple inheritance avoiding any ambiguities.&lt;br /&gt;
&lt;br /&gt;
The below code in Ruby demonstrates two modules Frog and Dinosaur, each of which contain the talk method defined in them. The Frogsaur class ''includes'' these two methods and defines its own talk method. This example was chosen to exhibit on how Ruby resolves method calls at run time.&lt;br /&gt;
&lt;br /&gt;
  module Frog&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can croak&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  module Dinosaur&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can roar&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  class Frogsaur&lt;br /&gt;
      include Frog &lt;br /&gt;
      include Dinosaur&lt;br /&gt;
         def talk&lt;br /&gt;
             puts &amp;quot;I can roar like a dinosaur and croak like a frog&amp;quot;&lt;br /&gt;
         end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  fs = Frogsaur.new &lt;br /&gt;
  fs.talk         # -&amp;gt; Which talk method to call ??&lt;br /&gt;
&lt;br /&gt;
When the method talk is called on the Frogsaur object, Ruby makes sure that the latest method defined in the hierarchy is chosen. Here in this example, the talk method in the Frogsaur class is defined the latest and hence “I can roar like a dinosaur and croak like a frog” is printed. If there was no method defined in the class, method from the Dinosaur is printed since it is next in the hierarchy specified by the include statements.&lt;br /&gt;
&lt;br /&gt;
=Comparison between Mixins and Interfaces=&lt;br /&gt;
&lt;br /&gt;
This is a general comparision: &lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, modules have the implementation of the methods. So all the classes which include the modules gets the same Implementation because  classes create a reference to these modules.&lt;br /&gt;
|In Java, all classes which implement the interfaces should provide implementation for each of the methods declared in the interface. This might duplicate the code if the two or more classes have similar functionality.&lt;br /&gt;
|-&lt;br /&gt;
| The size of the code is relatively smaller because the classes automatically get access to methods defined in the modules. Modules server as a central repository&lt;br /&gt;
| The size is relatively larger because a class implementing more than one interfaces has to provide implementation.&lt;br /&gt;
|-&lt;br /&gt;
| Having more modules in the classes can make code less readable. Ideally mixins are suitable for small teams having few modules. &lt;br /&gt;
| The code is more readable here as the implementation is provided to each method and can be found in place&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, a method inside a module can have Module name as qualifier. Hence it’s possible for a class to have inherit two or more modules which have same names.&lt;br /&gt;
| In Java, the class itself has to provide the implementation of the methods. Inheriting methods of same names from different interfaces will signal an error message.&lt;br /&gt;
|-&lt;br /&gt;
| Modules cannot be inherited and cannot form is-a hierarchy&lt;br /&gt;
| Interfaces can extend another interface and hence can form is-a hierarchy&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Drawbacks of Mixins and Interfaces==&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces are also limited to public methods and constants with no implementation.&lt;br /&gt;
&lt;br /&gt;
=Conclusion=&lt;br /&gt;
Although mixins have certain advantages over interfaces, they possess their own share of disadvantages. Mixins are generally used in small frameworks and interfaces , more than solving the problem of multiple inheritance provide polymorphism feature which makes object-oriented code more flexible and easy to modify and maintain.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=See Also=&lt;br /&gt;
1. http://ruby.about.com/od/beginningruby/a/mixin.html&amp;lt;br&amp;gt;&lt;br /&gt;
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ &amp;lt;br&amp;gt;&lt;br /&gt;
3. https://www.re-motion.org/blogs/team/2008/02/20/introducing-mixins-finally/ &amp;lt;br&amp;gt;&lt;br /&gt;
4. https://www.cs.washington.edu/education/courses/cse413/11sp/lectures/ruby_interfaces-etc.pdf &amp;lt;br&amp;gt;&lt;br /&gt;
5. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&amp;amp;printable=yes &amp;lt;br&amp;gt;&lt;br /&gt;
6. http://csis.pace.edu/~bergin/patterns/multipleinheritance.html&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=51573</id>
		<title>CSC/ECE 517 Fall 2011/ch2 2c ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=51573"/>
		<updated>2011-09-30T19:51:40Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Approaches */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Mixins vs. Interfaces=&lt;br /&gt;
&lt;br /&gt;
=Introduction=&lt;br /&gt;
&lt;br /&gt;
In object oriented programming Mixins and Interfaces provide neat constructs to implement certain functionality and benefit from code re-usability. Understanding these constructs will benefit any programmer in designing any software with maximum polymorphic behavior and code re-usability. &lt;br /&gt;
&lt;br /&gt;
With the advent of object oriented languages, the designers of the language had to come up with the decision of whether or not to include the concept of multiple inheritance. Languages like C++ and Perl allow multiple inheritance whereas the designers of languages like C# and Java decided not to because of the problems associated with multiple inheritance&amp;lt;ref&amp;gt;[http://www.artima.com/intv/gosling13.html Inspiration for Interface]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
While [http://en.wikipedia.org/wiki/Java_%28programming_language%29 Java] like languages implemented interfaces to allow for [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism],languages like [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] opted not to implement multiple inheritance but to allow the code from one module be added into another class. &lt;br /&gt;
&lt;br /&gt;
Though both interfaces and Mixins simulate multiple inheritance and avoid the common pathologies associated with it , they have their own set of compromises. The below article tries to provide clarity on how this is achieved in each and also provides other distinctive features of Mixins and interfaces. &lt;br /&gt;
&lt;br /&gt;
===Interfaces===&lt;br /&gt;
In an object-oriented programming languages such as Java, C#, an interface&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/ Interfaces] &amp;lt;/ref&amp;gt; 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. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
&lt;br /&gt;
  public interface ParkingLot {&lt;br /&gt;
        boolean add(Car car, int slot);&lt;br /&gt;
        boolean remove(Car car);&lt;br /&gt;
        boolean findCar(Int number);&lt;br /&gt;
        int freeSlotsCount();&lt;br /&gt;
        int occupiedSlots();&lt;br /&gt;
        int parkingType();&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration);&lt;br /&gt;
        int findParkingSlot();&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
  public class Mall implements ParkingLot {&lt;br /&gt;
        boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }&lt;br /&gt;
        boolean remove(Car car){ // do something }&lt;br /&gt;
        boolean findCar(Int number){ // do something }&lt;br /&gt;
        int freeSlotsCount(){ // do something }&lt;br /&gt;
        int occupiedSlots(){ // do something }&lt;br /&gt;
        int parkingType(){ // do something }&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration){ // do something }&lt;br /&gt;
        int findParkingSlot(){ // do something }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
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. Interfaces provide an alternative  for languages like Java that does not allow multiple inheritance .&lt;br /&gt;
&lt;br /&gt;
In Java, a class can inherit from only one class but it can implement more than one interface. Therefore, objects can have multiple types: the type of their own class and the types of all the interfaces that they implement. This means that if a variable is declared to be the type of an interface, its value can reference any object that is instantiated from any class that implements the interface.&lt;br /&gt;
&lt;br /&gt;
==Mixins==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Modules are defined in Ruby using the ''module'' keyword.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;ref&amp;gt;[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Below is an example for modules and Mixins:&lt;br /&gt;
&lt;br /&gt;
The module ParkingSlot consists of the methods park and unpark&lt;br /&gt;
  &amp;lt;span style=&amp;quot;color:#4682B4&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingSlot&lt;br /&gt;
        def park&lt;br /&gt;
           #code to park the car&lt;br /&gt;
        end&lt;br /&gt;
        def unpark&lt;br /&gt;
           #code to unpark the car&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/span&amp;gt;&lt;br /&gt;
The module ParkingMeter consists of the methods calculate and printreceipt&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#F4A460&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingMeter&lt;br /&gt;
        def calculate&lt;br /&gt;
           #code to calculate the parking fee&lt;br /&gt;
        end&lt;br /&gt;
        def printreceipt&lt;br /&gt;
           #code to print the receipt&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
When a class ''includes'' a module via include Module Name, all the methods on that module become instance methods on the class.&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#6B8E23&amp;quot;&amp;gt;&lt;br /&gt;
  class Parking&lt;br /&gt;
       include ParkingSlot&lt;br /&gt;
       include ParkingMeter&lt;br /&gt;
       def printcardetails&lt;br /&gt;
           #code to print the details and type of car&lt;br /&gt;
       end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
  p=Parking.new   &lt;br /&gt;
  p.park            # -&amp;gt; Method park from module ParkingSlot&lt;br /&gt;
  p.unpark          # -&amp;gt; Method unpark from module ParkingSlot&lt;br /&gt;
  p.calculate       # -&amp;gt; Method calculate from module ParkingMeter&lt;br /&gt;
  p.printreceipt    # -&amp;gt; Method printreceipt from module ParkingMeter&lt;br /&gt;
  p.printcardetails # -&amp;gt; Calls printCarDetails from class&lt;br /&gt;
&lt;br /&gt;
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''.&lt;br /&gt;
&lt;br /&gt;
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 [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Subclasses_and_superclasses superclass].&lt;br /&gt;
&lt;br /&gt;
[[Image:ParkingLot.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
==Supported Languages==&lt;br /&gt;
The following table shows support for Mixins and Interfaces by most commonly used languages.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Languages&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| Ruby&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Java&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Python&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Smalltalk&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Perl&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| C#&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=Multiple Inheritance=&lt;br /&gt;
[http://en.wikipedia.org/wiki/Multiple_inheritance Multiple Inheritance] refers to a feature in some [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented programming] languages in which a class can inherit behaviors from more than one superclass. This contrasts with single inheritance in which a class can inherit behavior from at most one superclass. &lt;br /&gt;
Though Multiple Inheritance provides its own advantages of improved modularity and ease of reuse of code in certain applications, it has its own set of disadvantages which sometimes outweigh the possible advantages.&lt;br /&gt;
&lt;br /&gt;
==Diamond Problem==&lt;br /&gt;
This section describes the well know “Diamond Problem”&amp;lt;ref&amp;gt;[http://www.artima.com/designtechniques/interfaces2.html Diamond Problem] &amp;lt;/ref&amp;gt; associated with multiple Inheritance and the succeeding sections describe how Mixins and interfaces can be used to overcome this problem.&lt;br /&gt;
The diamond problem is the ambiguity that can occur when a class inherits from two different classes that both descend from a common superclass. For example, consider a scenario where one decides to combine the Frog and Dinosaur species which both are inherited from the Animal class. The talk() method in the Animal class is abstract and both Frog and Dinosaur needs to implement this method.&lt;br /&gt;
&lt;br /&gt;
Lets say both Frog and Dinosaur implement the talk method like this:&lt;br /&gt;
&lt;br /&gt;
    public class Frog extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Frog, I can croak “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
and,&lt;br /&gt;
    public class Dinosaur extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Dinosaur, I can roar “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
[[Image:Diamond_problem.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
When the Frogsaur is created, it inherits from both Frog and Dinosaur. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    public class Frogsaur extends Frog, Dinosaur {&lt;br /&gt;
       // Note below syntax is used just for demonstration. However java might throw compile time error.&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
The real problem occurs when someone tries to invoke talk() method on a Frogsaur object from the Animal reference.&lt;br /&gt;
    &lt;br /&gt;
    Animal species = new Frogsaur();&lt;br /&gt;
    species.talk(); // which method to invoke ???&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Due to the ambiguity caused by the diamond problem, it isn’t clear whether the runtime system should invoke Frog’s talk() method or Dinosaur talk() method.&lt;br /&gt;
&lt;br /&gt;
==Approaches==&lt;br /&gt;
Different programming languages have addressed the diamond problem in different ways.&lt;br /&gt;
&lt;br /&gt;
In Java, interfaces solve all these ambiguities caused by the diamond problem. Through interfaces, Java allows multiple inheritance of interface but not of implementation. Implementation, which includes instance variables and method implementations, is always singly inherited. As a result, confusion will never arise in Java over which inherited instance variable or method implementation to use.&lt;br /&gt;
&lt;br /&gt;
Ruby does not support multiple inheritance. Mixin provide a way which eliminates the need for multiple inheritance. Ruby has modules which are just like abstract classes&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/java/IandI/abstract.html Abstract Classes]&amp;lt;/ref&amp;gt; in Java. Modules can have different methods implemented in them. They cannot be instantiated like abstract classes. They cannot inherit from other modules or classes. Ruby classes can inherit from only one superclass but can have unlimited number of modules in them to exploit the usage of predefined implementations in these modules. This provides functionality similar to multiple inheritance avoiding any ambiguities.&lt;br /&gt;
&lt;br /&gt;
The below code in Ruby demonstrates two modules Frog and Dinosaur, each of which contain the talk method defined in them. The Frogsaur class ''includes'' these two methods and defines its own talk method. This example was chosen to exhibit on how Ruby resolves method calls at run time.&lt;br /&gt;
&lt;br /&gt;
  module Frog&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can croak&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  module Dinosaur&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can roar&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  class Frogsaur&lt;br /&gt;
      include Frog &lt;br /&gt;
      include Dinosaur&lt;br /&gt;
         def talk&lt;br /&gt;
             puts &amp;quot;I can roar like a dinosaur and croak like a frog&amp;quot;&lt;br /&gt;
         end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  fs = Frogsaur.new &lt;br /&gt;
  fs.talk         # -&amp;gt; Which talk method to call ??&lt;br /&gt;
&lt;br /&gt;
When the method talk is called on the Frogsaur object, Ruby makes sure that the latest method defined in the hierarchy is chosen. Here in this example, the talk method in the Frogsaur class is defined the latest and hence “I can roar like a dinosaur and croak like a frog” is printed. If there was no method defined in the class, method from the Dinosaur is printed since it is next in the hierarchy specified by the include statements.&lt;br /&gt;
&lt;br /&gt;
=Comparison between Mixins and Interfaces=&lt;br /&gt;
&lt;br /&gt;
This is a general comparision: &lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, modules have the implementation of the methods. So all the classes which include the modules gets the same Implementation because  classes create a reference to these modules.&lt;br /&gt;
|In Java, all classes which implement the interfaces should provide implementation for each of the methods declared in the interface. This might duplicate the code if the two or more classes have similar functionality.&lt;br /&gt;
|-&lt;br /&gt;
| The size of the code is relatively smaller because the classes automatically get access to methods defined in the modules. Modules server as a central repository&lt;br /&gt;
| The size is relatively larger because a class implementing more than one interfaces has to provide implementation.&lt;br /&gt;
|-&lt;br /&gt;
| Having more modules in the classes can make code less readable. Ideally mixins are suitable for small teams having few modules. &lt;br /&gt;
| The code is more readable here as the implementation is provided to each method and can be found in place&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, a method inside a module can have Module name as qualifier. Hence it’s possible for a class to have inherit two or more modules which have same names.&lt;br /&gt;
| In Java, the class itself has to provide the implementation of the methods. Inheriting methods of same names from different interfaces will signal an error message.&lt;br /&gt;
|-&lt;br /&gt;
| Modules cannot be inherited and cannot form is-a hierarchy&lt;br /&gt;
| Interfaces can extend another interface and hence can form is-a hierarchy&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Drawbacks of Mixins and Interfaces==&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces are also limited to public methods and constants with no implementation.&lt;br /&gt;
&lt;br /&gt;
=Conclusion=&lt;br /&gt;
Although mixins have certain advantages over interfaces, they possess their own share of disadvantages. Mixins are generally used in small frameworks and interfaces , more than solving the problem of multiple inheritance provide polymorphism feature which makes object-oriented code more flexible and easy to modify and maintain.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=See Also=&lt;br /&gt;
1. http://ruby.about.com/od/beginningruby/a/mixin.html&amp;lt;br&amp;gt;&lt;br /&gt;
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ &amp;lt;br&amp;gt;&lt;br /&gt;
3. https://www.re-motion.org/blogs/team/2008/02/20/introducing-mixins-finally/ &amp;lt;br&amp;gt;&lt;br /&gt;
4. https://www.cs.washington.edu/education/courses/cse413/11sp/lectures/ruby_interfaces-etc.pdf &amp;lt;br&amp;gt;&lt;br /&gt;
5. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&amp;amp;printable=yes &amp;lt;br&amp;gt;&lt;br /&gt;
6. http://csis.pace.edu/~bergin/patterns/multipleinheritance.html&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=51572</id>
		<title>CSC/ECE 517 Fall 2011/ch2 2c ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=51572"/>
		<updated>2011-09-30T19:44:05Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Interfaces */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Mixins vs. Interfaces=&lt;br /&gt;
&lt;br /&gt;
=Introduction=&lt;br /&gt;
&lt;br /&gt;
In object oriented programming Mixins and Interfaces provide neat constructs to implement certain functionality and benefit from code re-usability. Understanding these constructs will benefit any programmer in designing any software with maximum polymorphic behavior and code re-usability. &lt;br /&gt;
&lt;br /&gt;
With the advent of object oriented languages, the designers of the language had to come up with the decision of whether or not to include the concept of multiple inheritance. Languages like C++ and Perl allow multiple inheritance whereas the designers of languages like C# and Java decided not to because of the problems associated with multiple inheritance&amp;lt;ref&amp;gt;[http://www.artima.com/intv/gosling13.html Inspiration for Interface]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
While [http://en.wikipedia.org/wiki/Java_%28programming_language%29 Java] like languages implemented interfaces to allow for [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism],languages like [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] opted not to implement multiple inheritance but to allow the code from one module be added into another class. &lt;br /&gt;
&lt;br /&gt;
Though both interfaces and Mixins simulate multiple inheritance and avoid the common pathologies associated with it , they have their own set of compromises. The below article tries to provide clarity on how this is achieved in each and also provides other distinctive features of Mixins and interfaces. &lt;br /&gt;
&lt;br /&gt;
===Interfaces===&lt;br /&gt;
In an object-oriented programming languages such as Java, C#, an interface&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/ Interfaces] &amp;lt;/ref&amp;gt; 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. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
&lt;br /&gt;
  public interface ParkingLot {&lt;br /&gt;
        boolean add(Car car, int slot);&lt;br /&gt;
        boolean remove(Car car);&lt;br /&gt;
        boolean findCar(Int number);&lt;br /&gt;
        int freeSlotsCount();&lt;br /&gt;
        int occupiedSlots();&lt;br /&gt;
        int parkingType();&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration);&lt;br /&gt;
        int findParkingSlot();&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
  public class Mall implements ParkingLot {&lt;br /&gt;
        boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }&lt;br /&gt;
        boolean remove(Car car){ // do something }&lt;br /&gt;
        boolean findCar(Int number){ // do something }&lt;br /&gt;
        int freeSlotsCount(){ // do something }&lt;br /&gt;
        int occupiedSlots(){ // do something }&lt;br /&gt;
        int parkingType(){ // do something }&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration){ // do something }&lt;br /&gt;
        int findParkingSlot(){ // do something }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
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. Interfaces provide an alternative  for languages like Java that does not allow multiple inheritance .&lt;br /&gt;
&lt;br /&gt;
In Java, a class can inherit from only one class but it can implement more than one interface. Therefore, objects can have multiple types: the type of their own class and the types of all the interfaces that they implement. This means that if a variable is declared to be the type of an interface, its value can reference any object that is instantiated from any class that implements the interface.&lt;br /&gt;
&lt;br /&gt;
==Mixins==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Modules are defined in Ruby using the ''module'' keyword.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;ref&amp;gt;[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Below is an example for modules and Mixins:&lt;br /&gt;
&lt;br /&gt;
The module ParkingSlot consists of the methods park and unpark&lt;br /&gt;
  &amp;lt;span style=&amp;quot;color:#4682B4&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingSlot&lt;br /&gt;
        def park&lt;br /&gt;
           #code to park the car&lt;br /&gt;
        end&lt;br /&gt;
        def unpark&lt;br /&gt;
           #code to unpark the car&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/span&amp;gt;&lt;br /&gt;
The module ParkingMeter consists of the methods calculate and printreceipt&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#F4A460&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingMeter&lt;br /&gt;
        def calculate&lt;br /&gt;
           #code to calculate the parking fee&lt;br /&gt;
        end&lt;br /&gt;
        def printreceipt&lt;br /&gt;
           #code to print the receipt&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
When a class ''includes'' a module via include Module Name, all the methods on that module become instance methods on the class.&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#6B8E23&amp;quot;&amp;gt;&lt;br /&gt;
  class Parking&lt;br /&gt;
       include ParkingSlot&lt;br /&gt;
       include ParkingMeter&lt;br /&gt;
       def printcardetails&lt;br /&gt;
           #code to print the details and type of car&lt;br /&gt;
       end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
  p=Parking.new   &lt;br /&gt;
  p.park            # -&amp;gt; Method park from module ParkingSlot&lt;br /&gt;
  p.unpark          # -&amp;gt; Method unpark from module ParkingSlot&lt;br /&gt;
  p.calculate       # -&amp;gt; Method calculate from module ParkingMeter&lt;br /&gt;
  p.printreceipt    # -&amp;gt; Method printreceipt from module ParkingMeter&lt;br /&gt;
  p.printcardetails # -&amp;gt; Calls printCarDetails from class&lt;br /&gt;
&lt;br /&gt;
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''.&lt;br /&gt;
&lt;br /&gt;
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 [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Subclasses_and_superclasses superclass].&lt;br /&gt;
&lt;br /&gt;
[[Image:ParkingLot.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
==Supported Languages==&lt;br /&gt;
The following table shows support for Mixins and Interfaces by most commonly used languages.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Languages&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| Ruby&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Java&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Python&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Smalltalk&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Perl&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| C#&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=Multiple Inheritance=&lt;br /&gt;
[http://en.wikipedia.org/wiki/Multiple_inheritance Multiple Inheritance] refers to a feature in some [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented programming] languages in which a class can inherit behaviors from more than one superclass. This contrasts with single inheritance in which a class can inherit behavior from at most one superclass. &lt;br /&gt;
Though Multiple Inheritance provides its own advantages of improved modularity and ease of reuse of code in certain applications, it has its own set of disadvantages which sometimes outweigh the possible advantages.&lt;br /&gt;
&lt;br /&gt;
==Diamond Problem==&lt;br /&gt;
This section describes the well know “Diamond Problem”&amp;lt;ref&amp;gt;[http://www.artima.com/designtechniques/interfaces2.html Diamond Problem] &amp;lt;/ref&amp;gt; associated with multiple Inheritance and the succeeding sections describe how Mixins and interfaces can be used to overcome this problem.&lt;br /&gt;
The diamond problem is the ambiguity that can occur when a class inherits from two different classes that both descend from a common superclass. For example, consider a scenario where one decides to combine the Frog and Dinosaur species which both are inherited from the Animal class. The talk() method in the Animal class is abstract and both Frog and Dinosaur needs to implement this method.&lt;br /&gt;
&lt;br /&gt;
Lets say both Frog and Dinosaur implement the talk method like this:&lt;br /&gt;
&lt;br /&gt;
    public class Frog extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Frog, I can croak “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
and,&lt;br /&gt;
    public class Dinosaur extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Dinosaur, I can roar “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
[[Image:Diamond_problem.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
When the Frogsaur is created, it inherits from both Frog and Dinosaur. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    public class Frogsaur extends Frog, Dinosaur {&lt;br /&gt;
       // Note below syntax is used just for demonstration. However java might throw compile time error.&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
The real problem occurs when someone tries to invoke talk() method on a Frogsaur object from the Animal reference.&lt;br /&gt;
    &lt;br /&gt;
    Animal species = new Frogsaur();&lt;br /&gt;
    species.talk(); // which method to invoke ???&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Due to the ambiguity caused by the diamond problem, it isn’t clear whether the runtime system should invoke Frog’s talk() method or Dinosaur talk() method.&lt;br /&gt;
&lt;br /&gt;
==Approaches==&lt;br /&gt;
Different programming languages have addressed the diamond problem in different ways.&lt;br /&gt;
&lt;br /&gt;
In Java, interfaces solve all these ambiguities caused by the diamond problem. Through interfaces, Java allows multiple inheritance of interface but not of implementation. Implementation, which includes instance variables and method implementations, is always singly inherited. As a result, confusion will never arise in Java over which inherited instance variable or method implementation to use.&lt;br /&gt;
&lt;br /&gt;
Ruby does not support multiple inheritance. Mixin provide a way which eliminates the need for multiple inheritance. Ruby has modules which are just like abstract classes&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/java/IandI/abstract.html Abstract Classes]&amp;lt;/ref&amp;gt; in Java. Modules can have different methods implemented in them. They cannot be instantiated like abstract classes. They cannot inherit from other modules or classes. Ruby classes can inherit from only one superclass but can have unlimited number of modules in them to exploit the usage of predefined implementations in these modules. This provides functionality similar to multiple inheritance avoiding any ambiguities.&lt;br /&gt;
&lt;br /&gt;
The below code in Ruby demonstrates two modules Frog and Dinosaur, each of which contain the talk method defined in them. The Frogsaur class ''includes'' these two methods and defines its own talk method. This example was chosen to exhibit on how Ruby resolves method calls at run time.&lt;br /&gt;
&lt;br /&gt;
  module Frog&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can croak&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  module Dinosaur&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can roar&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  class Frogsaur&lt;br /&gt;
      include Frog &lt;br /&gt;
      include Dinosaur&lt;br /&gt;
         def talk&lt;br /&gt;
             puts &amp;quot;I can roar like a dinosaur and croak like a frog&amp;quot;&lt;br /&gt;
         end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  fs = Frogsaur.new&lt;br /&gt;
  fs.talk         # -&amp;gt; I can roar like a dinosaur and croak like a frog&lt;br /&gt;
&lt;br /&gt;
When the method talk is called on the Frogsaur object, Ruby makes sure that the latest method defined in the hierarchy is chosen. Here in this example, the talk method in the Frogsaur class is defined the latest and hence “I can roar like a dinosaur and croak like a frog” is printed. If there was no method defined in the class, method from the Dinosaur is printed since it is next in the hierarchy specified by the include statements.&lt;br /&gt;
&lt;br /&gt;
=Comparison between Mixins and Interfaces=&lt;br /&gt;
&lt;br /&gt;
This is a general comparision: &lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, modules have the implementation of the methods. So all the classes which include the modules gets the same Implementation because  classes create a reference to these modules.&lt;br /&gt;
|In Java, all classes which implement the interfaces should provide implementation for each of the methods declared in the interface. This might duplicate the code if the two or more classes have similar functionality.&lt;br /&gt;
|-&lt;br /&gt;
| The size of the code is relatively smaller because the classes automatically get access to methods defined in the modules. Modules server as a central repository&lt;br /&gt;
| The size is relatively larger because a class implementing more than one interfaces has to provide implementation.&lt;br /&gt;
|-&lt;br /&gt;
| Having more modules in the classes can make code less readable. Ideally mixins are suitable for small teams having few modules. &lt;br /&gt;
| The code is more readable here as the implementation is provided to each method and can be found in place&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, a method inside a module can have Module name as qualifier. Hence it’s possible for a class to have inherit two or more modules which have same names.&lt;br /&gt;
| In Java, the class itself has to provide the implementation of the methods. Inheriting methods of same names from different interfaces will signal an error message.&lt;br /&gt;
|-&lt;br /&gt;
| Modules cannot be inherited and cannot form is-a hierarchy&lt;br /&gt;
| Interfaces can extend another interface and hence can form is-a hierarchy&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Drawbacks of Mixins and Interfaces==&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces are also limited to public methods and constants with no implementation.&lt;br /&gt;
&lt;br /&gt;
=Conclusion=&lt;br /&gt;
Although mixins have certain advantages over interfaces, they possess their own share of disadvantages. Mixins are generally used in small frameworks and interfaces , more than solving the problem of multiple inheritance provide polymorphism feature which makes object-oriented code more flexible and easy to modify and maintain.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=See Also=&lt;br /&gt;
1. http://ruby.about.com/od/beginningruby/a/mixin.html&amp;lt;br&amp;gt;&lt;br /&gt;
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ &amp;lt;br&amp;gt;&lt;br /&gt;
3. https://www.re-motion.org/blogs/team/2008/02/20/introducing-mixins-finally/ &amp;lt;br&amp;gt;&lt;br /&gt;
4. https://www.cs.washington.edu/education/courses/cse413/11sp/lectures/ruby_interfaces-etc.pdf &amp;lt;br&amp;gt;&lt;br /&gt;
5. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&amp;amp;printable=yes &amp;lt;br&amp;gt;&lt;br /&gt;
6. http://csis.pace.edu/~bergin/patterns/multipleinheritance.html&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=51571</id>
		<title>CSC/ECE 517 Fall 2011/ch2 2c ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=51571"/>
		<updated>2011-09-30T19:43:15Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Interfaces */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Mixins vs. Interfaces=&lt;br /&gt;
&lt;br /&gt;
=Introduction=&lt;br /&gt;
&lt;br /&gt;
In object oriented programming Mixins and Interfaces provide neat constructs to implement certain functionality and benefit from code re-usability. Understanding these constructs will benefit any programmer in designing any software with maximum polymorphic behavior and code re-usability. &lt;br /&gt;
&lt;br /&gt;
With the advent of object oriented languages, the designers of the language had to come up with the decision of whether or not to include the concept of multiple inheritance. Languages like C++ and Perl allow multiple inheritance whereas the designers of languages like C# and Java decided not to because of the problems associated with multiple inheritance&amp;lt;ref&amp;gt;[http://www.artima.com/intv/gosling13.html Inspiration for Interface]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
While [http://en.wikipedia.org/wiki/Java_%28programming_language%29 Java] like languages implemented interfaces to allow for [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism],languages like [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] opted not to implement multiple inheritance but to allow the code from one module be added into another class. &lt;br /&gt;
&lt;br /&gt;
Though both interfaces and Mixins simulate multiple inheritance and avoid the common pathologies associated with it , they have their own set of compromises. The below article tries to provide clarity on how this is achieved in each and also provides other distinctive features of Mixins and interfaces. &lt;br /&gt;
&lt;br /&gt;
===Interfaces===&lt;br /&gt;
In an object-oriented programming languages such as Java, C#, an interface&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/ Interfaces] &amp;lt;/ref&amp;gt; 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. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
&lt;br /&gt;
  public interface ParkingLot {&lt;br /&gt;
        boolean add(Car car, int slot);&lt;br /&gt;
        boolean remove(Car car);&lt;br /&gt;
        boolean findCar(Int number);&lt;br /&gt;
        int freeSlotsCount();&lt;br /&gt;
        int occupiedSlots();&lt;br /&gt;
        int parkingType();&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration);&lt;br /&gt;
        int findParkingSlot();&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
  public class Mall implements ParkingLot {&lt;br /&gt;
        boolean add(Car car, int slot) { &lt;br /&gt;
&lt;br /&gt;
        //... Code to add a car into the parking lot... &lt;br /&gt;
          &lt;br /&gt;
        }&lt;br /&gt;
        boolean remove(Car car){ // do something }&lt;br /&gt;
        boolean findCar(Int number){ // do something }&lt;br /&gt;
        int freeSlotsCount(){ // do something }&lt;br /&gt;
        int occupiedSlots(){ // do something }&lt;br /&gt;
        int parkingType(){ // do something }&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration){ // do something }&lt;br /&gt;
        int findParkingSlot(){ // do something }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
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. Interfaces provide an alternative  for languages like Java that does not allow multiple inheritance .&lt;br /&gt;
&lt;br /&gt;
In Java, a class can inherit from only one class but it can implement more than one interface. Therefore, objects can have multiple types: the type of their own class and the types of all the interfaces that they implement. This means that if a variable is declared to be the type of an interface, its value can reference any object that is instantiated from any class that implements the interface.&lt;br /&gt;
&lt;br /&gt;
==Mixins==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Modules are defined in Ruby using the ''module'' keyword.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;ref&amp;gt;[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Below is an example for modules and Mixins:&lt;br /&gt;
&lt;br /&gt;
The module ParkingSlot consists of the methods park and unpark&lt;br /&gt;
  &amp;lt;span style=&amp;quot;color:#4682B4&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingSlot&lt;br /&gt;
        def park&lt;br /&gt;
           #code to park the car&lt;br /&gt;
        end&lt;br /&gt;
        def unpark&lt;br /&gt;
           #code to unpark the car&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/span&amp;gt;&lt;br /&gt;
The module ParkingMeter consists of the methods calculate and printreceipt&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#F4A460&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingMeter&lt;br /&gt;
        def calculate&lt;br /&gt;
           #code to calculate the parking fee&lt;br /&gt;
        end&lt;br /&gt;
        def printreceipt&lt;br /&gt;
           #code to print the receipt&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
When a class ''includes'' a module via include Module Name, all the methods on that module become instance methods on the class.&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#6B8E23&amp;quot;&amp;gt;&lt;br /&gt;
  class Parking&lt;br /&gt;
       include ParkingSlot&lt;br /&gt;
       include ParkingMeter&lt;br /&gt;
       def printcardetails&lt;br /&gt;
           #code to print the details and type of car&lt;br /&gt;
       end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
  p=Parking.new   &lt;br /&gt;
  p.park            # -&amp;gt; Method park from module ParkingSlot&lt;br /&gt;
  p.unpark          # -&amp;gt; Method unpark from module ParkingSlot&lt;br /&gt;
  p.calculate       # -&amp;gt; Method calculate from module ParkingMeter&lt;br /&gt;
  p.printreceipt    # -&amp;gt; Method printreceipt from module ParkingMeter&lt;br /&gt;
  p.printcardetails # -&amp;gt; Calls printCarDetails from class&lt;br /&gt;
&lt;br /&gt;
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''.&lt;br /&gt;
&lt;br /&gt;
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 [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Subclasses_and_superclasses superclass].&lt;br /&gt;
&lt;br /&gt;
[[Image:ParkingLot.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
==Supported Languages==&lt;br /&gt;
The following table shows support for Mixins and Interfaces by most commonly used languages.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Languages&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| Ruby&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Java&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Python&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Smalltalk&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Perl&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| C#&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=Multiple Inheritance=&lt;br /&gt;
[http://en.wikipedia.org/wiki/Multiple_inheritance Multiple Inheritance] refers to a feature in some [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented programming] languages in which a class can inherit behaviors from more than one superclass. This contrasts with single inheritance in which a class can inherit behavior from at most one superclass. &lt;br /&gt;
Though Multiple Inheritance provides its own advantages of improved modularity and ease of reuse of code in certain applications, it has its own set of disadvantages which sometimes outweigh the possible advantages.&lt;br /&gt;
&lt;br /&gt;
==Diamond Problem==&lt;br /&gt;
This section describes the well know “Diamond Problem”&amp;lt;ref&amp;gt;[http://www.artima.com/designtechniques/interfaces2.html Diamond Problem] &amp;lt;/ref&amp;gt; associated with multiple Inheritance and the succeeding sections describe how Mixins and interfaces can be used to overcome this problem.&lt;br /&gt;
The diamond problem is the ambiguity that can occur when a class inherits from two different classes that both descend from a common superclass. For example, consider a scenario where one decides to combine the Frog and Dinosaur species which both are inherited from the Animal class. The talk() method in the Animal class is abstract and both Frog and Dinosaur needs to implement this method.&lt;br /&gt;
&lt;br /&gt;
Lets say both Frog and Dinosaur implement the talk method like this:&lt;br /&gt;
&lt;br /&gt;
    public class Frog extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Frog, I can croak “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
and,&lt;br /&gt;
    public class Dinosaur extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Dinosaur, I can roar “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
[[Image:Diamond_problem.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
When the Frogsaur is created, it inherits from both Frog and Dinosaur. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    public class Frogsaur extends Frog, Dinosaur {&lt;br /&gt;
       // Note below syntax is used just for demonstration. However java might throw compile time error.&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
The real problem occurs when someone tries to invoke talk() method on a Frogsaur object from the Animal reference.&lt;br /&gt;
    &lt;br /&gt;
    Animal species = new Frogsaur();&lt;br /&gt;
    species.talk(); // which method to invoke ???&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Due to the ambiguity caused by the diamond problem, it isn’t clear whether the runtime system should invoke Frog’s talk() method or Dinosaur talk() method.&lt;br /&gt;
&lt;br /&gt;
==Approaches==&lt;br /&gt;
Different programming languages have addressed the diamond problem in different ways.&lt;br /&gt;
&lt;br /&gt;
In Java, interfaces solve all these ambiguities caused by the diamond problem. Through interfaces, Java allows multiple inheritance of interface but not of implementation. Implementation, which includes instance variables and method implementations, is always singly inherited. As a result, confusion will never arise in Java over which inherited instance variable or method implementation to use.&lt;br /&gt;
&lt;br /&gt;
Ruby does not support multiple inheritance. Mixin provide a way which eliminates the need for multiple inheritance. Ruby has modules which are just like abstract classes&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/java/IandI/abstract.html Abstract Classes]&amp;lt;/ref&amp;gt; in Java. Modules can have different methods implemented in them. They cannot be instantiated like abstract classes. They cannot inherit from other modules or classes. Ruby classes can inherit from only one superclass but can have unlimited number of modules in them to exploit the usage of predefined implementations in these modules. This provides functionality similar to multiple inheritance avoiding any ambiguities.&lt;br /&gt;
&lt;br /&gt;
The below code in Ruby demonstrates two modules Frog and Dinosaur, each of which contain the talk method defined in them. The Frogsaur class ''includes'' these two methods and defines its own talk method. This example was chosen to exhibit on how Ruby resolves method calls at run time.&lt;br /&gt;
&lt;br /&gt;
  module Frog&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can croak&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  module Dinosaur&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can roar&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  class Frogsaur&lt;br /&gt;
      include Frog &lt;br /&gt;
      include Dinosaur&lt;br /&gt;
         def talk&lt;br /&gt;
             puts &amp;quot;I can roar like a dinosaur and croak like a frog&amp;quot;&lt;br /&gt;
         end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  fs = Frogsaur.new&lt;br /&gt;
  fs.talk         # -&amp;gt; I can roar like a dinosaur and croak like a frog&lt;br /&gt;
&lt;br /&gt;
When the method talk is called on the Frogsaur object, Ruby makes sure that the latest method defined in the hierarchy is chosen. Here in this example, the talk method in the Frogsaur class is defined the latest and hence “I can roar like a dinosaur and croak like a frog” is printed. If there was no method defined in the class, method from the Dinosaur is printed since it is next in the hierarchy specified by the include statements.&lt;br /&gt;
&lt;br /&gt;
=Comparison between Mixins and Interfaces=&lt;br /&gt;
&lt;br /&gt;
This is a general comparision: &lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, modules have the implementation of the methods. So all the classes which include the modules gets the same Implementation because  classes create a reference to these modules.&lt;br /&gt;
|In Java, all classes which implement the interfaces should provide implementation for each of the methods declared in the interface. This might duplicate the code if the two or more classes have similar functionality.&lt;br /&gt;
|-&lt;br /&gt;
| The size of the code is relatively smaller because the classes automatically get access to methods defined in the modules. Modules server as a central repository&lt;br /&gt;
| The size is relatively larger because a class implementing more than one interfaces has to provide implementation.&lt;br /&gt;
|-&lt;br /&gt;
| Having more modules in the classes can make code less readable. Ideally mixins are suitable for small teams having few modules. &lt;br /&gt;
| The code is more readable here as the implementation is provided to each method and can be found in place&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, a method inside a module can have Module name as qualifier. Hence it’s possible for a class to have inherit two or more modules which have same names.&lt;br /&gt;
| In Java, the class itself has to provide the implementation of the methods. Inheriting methods of same names from different interfaces will signal an error message.&lt;br /&gt;
|-&lt;br /&gt;
| Modules cannot be inherited and cannot form is-a hierarchy&lt;br /&gt;
| Interfaces can extend another interface and hence can form is-a hierarchy&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Drawbacks of Mixins and Interfaces==&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces are also limited to public methods and constants with no implementation.&lt;br /&gt;
&lt;br /&gt;
=Conclusion=&lt;br /&gt;
Although mixins have certain advantages over interfaces, they possess their own share of disadvantages. Mixins are generally used in small frameworks and interfaces , more than solving the problem of multiple inheritance provide polymorphism feature which makes object-oriented code more flexible and easy to modify and maintain.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=See Also=&lt;br /&gt;
1. http://ruby.about.com/od/beginningruby/a/mixin.html&amp;lt;br&amp;gt;&lt;br /&gt;
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ &amp;lt;br&amp;gt;&lt;br /&gt;
3. https://www.re-motion.org/blogs/team/2008/02/20/introducing-mixins-finally/ &amp;lt;br&amp;gt;&lt;br /&gt;
4. https://www.cs.washington.edu/education/courses/cse413/11sp/lectures/ruby_interfaces-etc.pdf &amp;lt;br&amp;gt;&lt;br /&gt;
5. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&amp;amp;printable=yes &amp;lt;br&amp;gt;&lt;br /&gt;
6. http://csis.pace.edu/~bergin/patterns/multipleinheritance.html&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=51570</id>
		<title>CSC/ECE 517 Fall 2011/ch2 2c ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=51570"/>
		<updated>2011-09-30T19:42:19Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Interfaces */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Mixins vs. Interfaces=&lt;br /&gt;
&lt;br /&gt;
=Introduction=&lt;br /&gt;
&lt;br /&gt;
In object oriented programming Mixins and Interfaces provide neat constructs to implement certain functionality and benefit from code re-usability. Understanding these constructs will benefit any programmer in designing any software with maximum polymorphic behavior and code re-usability. &lt;br /&gt;
&lt;br /&gt;
With the advent of object oriented languages, the designers of the language had to come up with the decision of whether or not to include the concept of multiple inheritance. Languages like C++ and Perl allow multiple inheritance whereas the designers of languages like C# and Java decided not to because of the problems associated with multiple inheritance&amp;lt;ref&amp;gt;[http://www.artima.com/intv/gosling13.html Inspiration for Interface]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
While [http://en.wikipedia.org/wiki/Java_%28programming_language%29 Java] like languages implemented interfaces to allow for [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism],languages like [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] opted not to implement multiple inheritance but to allow the code from one module be added into another class. &lt;br /&gt;
&lt;br /&gt;
Though both interfaces and Mixins simulate multiple inheritance and avoid the common pathologies associated with it , they have their own set of compromises. The below article tries to provide clarity on how this is achieved in each and also provides other distinctive features of Mixins and interfaces. &lt;br /&gt;
&lt;br /&gt;
===Interfaces===&lt;br /&gt;
In an object-oriented programming languages such as Java, C#, an interface&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/ Interfaces] &amp;lt;/ref&amp;gt; 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. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
&lt;br /&gt;
  public interface ParkingLot {&lt;br /&gt;
        boolean add(Car car, int slot);&lt;br /&gt;
        boolean remove(Car car);&lt;br /&gt;
        boolean findCar(Int number);&lt;br /&gt;
        int freeSlotsCount();&lt;br /&gt;
        int occupiedSlots();&lt;br /&gt;
        int parkingType();&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration);&lt;br /&gt;
        int findParkingSlot();&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
  public class Mall implements ParkingLot {&lt;br /&gt;
         boolean add(Car car, int slot) { &lt;br /&gt;
&lt;br /&gt;
        //... Code to add a car into the parking lot... &lt;br /&gt;
          &lt;br /&gt;
        }&lt;br /&gt;
        boolean remove(Car car){ // do something }&lt;br /&gt;
        boolean findCar(Int number){ // do something }&lt;br /&gt;
        int freeSlotsCount(){ // do something }&lt;br /&gt;
        int occupiedSlots(){ // do something }&lt;br /&gt;
        int parkingType(){ // do something }&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration){ // do something }&lt;br /&gt;
        int findParkingSlot(){ // do something }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
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. Interfaces provide an alternative  for languages like Java that does not allow multiple inheritance .&lt;br /&gt;
&lt;br /&gt;
In Java, a class can inherit from only one class but it can implement more than one interface. Therefore, objects can have multiple types: the type of their own class and the types of all the interfaces that they implement. This means that if a variable is declared to be the type of an interface, its value can reference any object that is instantiated from any class that implements the interface.&lt;br /&gt;
&lt;br /&gt;
==Mixins==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Modules are defined in Ruby using the ''module'' keyword.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;ref&amp;gt;[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Below is an example for modules and Mixins:&lt;br /&gt;
&lt;br /&gt;
The module ParkingSlot consists of the methods park and unpark&lt;br /&gt;
  &amp;lt;span style=&amp;quot;color:#4682B4&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingSlot&lt;br /&gt;
        def park&lt;br /&gt;
           #code to park the car&lt;br /&gt;
        end&lt;br /&gt;
        def unpark&lt;br /&gt;
           #code to unpark the car&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/span&amp;gt;&lt;br /&gt;
The module ParkingMeter consists of the methods calculate and printreceipt&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#F4A460&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingMeter&lt;br /&gt;
        def calculate&lt;br /&gt;
           #code to calculate the parking fee&lt;br /&gt;
        end&lt;br /&gt;
        def printreceipt&lt;br /&gt;
           #code to print the receipt&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
When a class ''includes'' a module via include Module Name, all the methods on that module become instance methods on the class.&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#6B8E23&amp;quot;&amp;gt;&lt;br /&gt;
  class Parking&lt;br /&gt;
       include ParkingSlot&lt;br /&gt;
       include ParkingMeter&lt;br /&gt;
       def printcardetails&lt;br /&gt;
           #code to print the details and type of car&lt;br /&gt;
       end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
  p=Parking.new   &lt;br /&gt;
  p.park            # -&amp;gt; Method park from module ParkingSlot&lt;br /&gt;
  p.unpark          # -&amp;gt; Method unpark from module ParkingSlot&lt;br /&gt;
  p.calculate       # -&amp;gt; Method calculate from module ParkingMeter&lt;br /&gt;
  p.printreceipt    # -&amp;gt; Method printreceipt from module ParkingMeter&lt;br /&gt;
  p.printcardetails # -&amp;gt; Calls printCarDetails from class&lt;br /&gt;
&lt;br /&gt;
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''.&lt;br /&gt;
&lt;br /&gt;
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 [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Subclasses_and_superclasses superclass].&lt;br /&gt;
&lt;br /&gt;
[[Image:ParkingLot.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
==Supported Languages==&lt;br /&gt;
The following table shows support for Mixins and Interfaces by most commonly used languages.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Languages&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| Ruby&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Java&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Python&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Smalltalk&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Perl&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| C#&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=Multiple Inheritance=&lt;br /&gt;
[http://en.wikipedia.org/wiki/Multiple_inheritance Multiple Inheritance] refers to a feature in some [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented programming] languages in which a class can inherit behaviors from more than one superclass. This contrasts with single inheritance in which a class can inherit behavior from at most one superclass. &lt;br /&gt;
Though Multiple Inheritance provides its own advantages of improved modularity and ease of reuse of code in certain applications, it has its own set of disadvantages which sometimes outweigh the possible advantages.&lt;br /&gt;
&lt;br /&gt;
==Diamond Problem==&lt;br /&gt;
This section describes the well know “Diamond Problem”&amp;lt;ref&amp;gt;[http://www.artima.com/designtechniques/interfaces2.html Diamond Problem] &amp;lt;/ref&amp;gt; associated with multiple Inheritance and the succeeding sections describe how Mixins and interfaces can be used to overcome this problem.&lt;br /&gt;
The diamond problem is the ambiguity that can occur when a class inherits from two different classes that both descend from a common superclass. For example, consider a scenario where one decides to combine the Frog and Dinosaur species which both are inherited from the Animal class. The talk() method in the Animal class is abstract and both Frog and Dinosaur needs to implement this method.&lt;br /&gt;
&lt;br /&gt;
Lets say both Frog and Dinosaur implement the talk method like this:&lt;br /&gt;
&lt;br /&gt;
    public class Frog extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Frog, I can croak “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
and,&lt;br /&gt;
    public class Dinosaur extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Dinosaur, I can roar “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
[[Image:Diamond_problem.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
When the Frogsaur is created, it inherits from both Frog and Dinosaur. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    public class Frogsaur extends Frog, Dinosaur {&lt;br /&gt;
       // Note below syntax is used just for demonstration. However java might throw compile time error.&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
The real problem occurs when someone tries to invoke talk() method on a Frogsaur object from the Animal reference.&lt;br /&gt;
    &lt;br /&gt;
    Animal species = new Frogsaur();&lt;br /&gt;
    species.talk(); // which method to invoke ???&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Due to the ambiguity caused by the diamond problem, it isn’t clear whether the runtime system should invoke Frog’s talk() method or Dinosaur talk() method.&lt;br /&gt;
&lt;br /&gt;
==Approaches==&lt;br /&gt;
Different programming languages have addressed the diamond problem in different ways.&lt;br /&gt;
&lt;br /&gt;
In Java, interfaces solve all these ambiguities caused by the diamond problem. Through interfaces, Java allows multiple inheritance of interface but not of implementation. Implementation, which includes instance variables and method implementations, is always singly inherited. As a result, confusion will never arise in Java over which inherited instance variable or method implementation to use.&lt;br /&gt;
&lt;br /&gt;
Ruby does not support multiple inheritance. Mixin provide a way which eliminates the need for multiple inheritance. Ruby has modules which are just like abstract classes&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/java/IandI/abstract.html Abstract Classes]&amp;lt;/ref&amp;gt; in Java. Modules can have different methods implemented in them. They cannot be instantiated like abstract classes. They cannot inherit from other modules or classes. Ruby classes can inherit from only one superclass but can have unlimited number of modules in them to exploit the usage of predefined implementations in these modules. This provides functionality similar to multiple inheritance avoiding any ambiguities.&lt;br /&gt;
&lt;br /&gt;
The below code in Ruby demonstrates two modules Frog and Dinosaur, each of which contain the talk method defined in them. The Frogsaur class ''includes'' these two methods and defines its own talk method. This example was chosen to exhibit on how Ruby resolves method calls at run time.&lt;br /&gt;
&lt;br /&gt;
  module Frog&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can croak&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  module Dinosaur&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can roar&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  class Frogsaur&lt;br /&gt;
      include Frog &lt;br /&gt;
      include Dinosaur&lt;br /&gt;
         def talk&lt;br /&gt;
             puts &amp;quot;I can roar like a dinosaur and croak like a frog&amp;quot;&lt;br /&gt;
         end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  fs = Frogsaur.new&lt;br /&gt;
  fs.talk         # -&amp;gt; I can roar like a dinosaur and croak like a frog&lt;br /&gt;
&lt;br /&gt;
When the method talk is called on the Frogsaur object, Ruby makes sure that the latest method defined in the hierarchy is chosen. Here in this example, the talk method in the Frogsaur class is defined the latest and hence “I can roar like a dinosaur and croak like a frog” is printed. If there was no method defined in the class, method from the Dinosaur is printed since it is next in the hierarchy specified by the include statements.&lt;br /&gt;
&lt;br /&gt;
=Comparison between Mixins and Interfaces=&lt;br /&gt;
&lt;br /&gt;
This is a general comparision: &lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, modules have the implementation of the methods. So all the classes which include the modules gets the same Implementation because  classes create a reference to these modules.&lt;br /&gt;
|In Java, all classes which implement the interfaces should provide implementation for each of the methods declared in the interface. This might duplicate the code if the two or more classes have similar functionality.&lt;br /&gt;
|-&lt;br /&gt;
| The size of the code is relatively smaller because the classes automatically get access to methods defined in the modules. Modules server as a central repository&lt;br /&gt;
| The size is relatively larger because a class implementing more than one interfaces has to provide implementation.&lt;br /&gt;
|-&lt;br /&gt;
| Having more modules in the classes can make code less readable. Ideally mixins are suitable for small teams having few modules. &lt;br /&gt;
| The code is more readable here as the implementation is provided to each method and can be found in place&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, a method inside a module can have Module name as qualifier. Hence it’s possible for a class to have inherit two or more modules which have same names.&lt;br /&gt;
| In Java, the class itself has to provide the implementation of the methods. Inheriting methods of same names from different interfaces will signal an error message.&lt;br /&gt;
|-&lt;br /&gt;
| Modules cannot be inherited and cannot form is-a hierarchy&lt;br /&gt;
| Interfaces can extend another interface and hence can form is-a hierarchy&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Drawbacks of Mixins and Interfaces==&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces are also limited to public methods and constants with no implementation.&lt;br /&gt;
&lt;br /&gt;
=Conclusion=&lt;br /&gt;
Although mixins have certain advantages over interfaces, they possess their own share of disadvantages. Mixins are generally used in small frameworks and interfaces , more than solving the problem of multiple inheritance provide polymorphism feature which makes object-oriented code more flexible and easy to modify and maintain.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=See Also=&lt;br /&gt;
1. http://ruby.about.com/od/beginningruby/a/mixin.html&amp;lt;br&amp;gt;&lt;br /&gt;
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ &amp;lt;br&amp;gt;&lt;br /&gt;
3. https://www.re-motion.org/blogs/team/2008/02/20/introducing-mixins-finally/ &amp;lt;br&amp;gt;&lt;br /&gt;
4. https://www.cs.washington.edu/education/courses/cse413/11sp/lectures/ruby_interfaces-etc.pdf &amp;lt;br&amp;gt;&lt;br /&gt;
5. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&amp;amp;printable=yes &amp;lt;br&amp;gt;&lt;br /&gt;
6. http://csis.pace.edu/~bergin/patterns/multipleinheritance.html&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=51569</id>
		<title>CSC/ECE 517 Fall 2011/ch2 2c ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=51569"/>
		<updated>2011-09-30T19:41:46Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Interfaces */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Mixins vs. Interfaces=&lt;br /&gt;
&lt;br /&gt;
=Introduction=&lt;br /&gt;
&lt;br /&gt;
In object oriented programming Mixins and Interfaces provide neat constructs to implement certain functionality and benefit from code re-usability. Understanding these constructs will benefit any programmer in designing any software with maximum polymorphic behavior and code re-usability. &lt;br /&gt;
&lt;br /&gt;
With the advent of object oriented languages, the designers of the language had to come up with the decision of whether or not to include the concept of multiple inheritance. Languages like C++ and Perl allow multiple inheritance whereas the designers of languages like C# and Java decided not to because of the problems associated with multiple inheritance&amp;lt;ref&amp;gt;[http://www.artima.com/intv/gosling13.html Inspiration for Interface]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
While [http://en.wikipedia.org/wiki/Java_%28programming_language%29 Java] like languages implemented interfaces to allow for [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism],languages like [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] opted not to implement multiple inheritance but to allow the code from one module be added into another class. &lt;br /&gt;
&lt;br /&gt;
Though both interfaces and Mixins simulate multiple inheritance and avoid the common pathologies associated with it , they have their own set of compromises. The below article tries to provide clarity on how this is achieved in each and also provides other distinctive features of Mixins and interfaces. &lt;br /&gt;
&lt;br /&gt;
===Interfaces===&lt;br /&gt;
In an object-oriented programming languages such as Java, C#, an interface&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/ Interfaces] &amp;lt;/ref&amp;gt; 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. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
&lt;br /&gt;
  public interface ParkingLot {&lt;br /&gt;
        boolean add(Car car, int slot);&lt;br /&gt;
        boolean remove(Car car);&lt;br /&gt;
        boolean findCar(Int number);&lt;br /&gt;
        int freeSlotsCount();&lt;br /&gt;
        int occupiedSlots();&lt;br /&gt;
        int parkingType();&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration);&lt;br /&gt;
        int findParkingSlot();&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
  public class Mall implements ParkingLot {&lt;br /&gt;
         boolean add(Car car, int slot) { &lt;br /&gt;
&lt;br /&gt;
         //... Code to add a car into the parking lot... &lt;br /&gt;
          &lt;br /&gt;
        }&lt;br /&gt;
        boolean remove(Car car){ // do something }&lt;br /&gt;
        boolean findCar(Int number){ // do something }&lt;br /&gt;
        int freeSlotsCount(){ // do something }&lt;br /&gt;
        int occupiedSlots(){ // do something }&lt;br /&gt;
        int parkingType(){ // do something }&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration){ // do something }&lt;br /&gt;
        int findParkingSlot(){ // do something }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
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. Interfaces provide an alternative  for languages like Java that does not allow multiple inheritance .&lt;br /&gt;
&lt;br /&gt;
In Java, a class can inherit from only one class but it can implement more than one interface. Therefore, objects can have multiple types: the type of their own class and the types of all the interfaces that they implement. This means that if a variable is declared to be the type of an interface, its value can reference any object that is instantiated from any class that implements the interface.&lt;br /&gt;
&lt;br /&gt;
==Mixins==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Modules are defined in Ruby using the ''module'' keyword.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;ref&amp;gt;[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Below is an example for modules and Mixins:&lt;br /&gt;
&lt;br /&gt;
The module ParkingSlot consists of the methods park and unpark&lt;br /&gt;
  &amp;lt;span style=&amp;quot;color:#4682B4&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingSlot&lt;br /&gt;
        def park&lt;br /&gt;
           #code to park the car&lt;br /&gt;
        end&lt;br /&gt;
        def unpark&lt;br /&gt;
           #code to unpark the car&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/span&amp;gt;&lt;br /&gt;
The module ParkingMeter consists of the methods calculate and printreceipt&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#F4A460&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingMeter&lt;br /&gt;
        def calculate&lt;br /&gt;
           #code to calculate the parking fee&lt;br /&gt;
        end&lt;br /&gt;
        def printreceipt&lt;br /&gt;
           #code to print the receipt&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
When a class ''includes'' a module via include Module Name, all the methods on that module become instance methods on the class.&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#6B8E23&amp;quot;&amp;gt;&lt;br /&gt;
  class Parking&lt;br /&gt;
       include ParkingSlot&lt;br /&gt;
       include ParkingMeter&lt;br /&gt;
       def printcardetails&lt;br /&gt;
           #code to print the details and type of car&lt;br /&gt;
       end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
  p=Parking.new   &lt;br /&gt;
  p.park            # -&amp;gt; Method park from module ParkingSlot&lt;br /&gt;
  p.unpark          # -&amp;gt; Method unpark from module ParkingSlot&lt;br /&gt;
  p.calculate       # -&amp;gt; Method calculate from module ParkingMeter&lt;br /&gt;
  p.printreceipt    # -&amp;gt; Method printreceipt from module ParkingMeter&lt;br /&gt;
  p.printcardetails # -&amp;gt; Calls printCarDetails from class&lt;br /&gt;
&lt;br /&gt;
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''.&lt;br /&gt;
&lt;br /&gt;
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 [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Subclasses_and_superclasses superclass].&lt;br /&gt;
&lt;br /&gt;
[[Image:ParkingLot.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
==Supported Languages==&lt;br /&gt;
The following table shows support for Mixins and Interfaces by most commonly used languages.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Languages&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| Ruby&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Java&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Python&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Smalltalk&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Perl&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| C#&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=Multiple Inheritance=&lt;br /&gt;
[http://en.wikipedia.org/wiki/Multiple_inheritance Multiple Inheritance] refers to a feature in some [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented programming] languages in which a class can inherit behaviors from more than one superclass. This contrasts with single inheritance in which a class can inherit behavior from at most one superclass. &lt;br /&gt;
Though Multiple Inheritance provides its own advantages of improved modularity and ease of reuse of code in certain applications, it has its own set of disadvantages which sometimes outweigh the possible advantages.&lt;br /&gt;
&lt;br /&gt;
==Diamond Problem==&lt;br /&gt;
This section describes the well know “Diamond Problem”&amp;lt;ref&amp;gt;[http://www.artima.com/designtechniques/interfaces2.html Diamond Problem] &amp;lt;/ref&amp;gt; associated with multiple Inheritance and the succeeding sections describe how Mixins and interfaces can be used to overcome this problem.&lt;br /&gt;
The diamond problem is the ambiguity that can occur when a class inherits from two different classes that both descend from a common superclass. For example, consider a scenario where one decides to combine the Frog and Dinosaur species which both are inherited from the Animal class. The talk() method in the Animal class is abstract and both Frog and Dinosaur needs to implement this method.&lt;br /&gt;
&lt;br /&gt;
Lets say both Frog and Dinosaur implement the talk method like this:&lt;br /&gt;
&lt;br /&gt;
    public class Frog extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Frog, I can croak “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
and,&lt;br /&gt;
    public class Dinosaur extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Dinosaur, I can roar “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
[[Image:Diamond_problem.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
When the Frogsaur is created, it inherits from both Frog and Dinosaur. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    public class Frogsaur extends Frog, Dinosaur {&lt;br /&gt;
       // Note below syntax is used just for demonstration. However java might throw compile time error.&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
The real problem occurs when someone tries to invoke talk() method on a Frogsaur object from the Animal reference.&lt;br /&gt;
    &lt;br /&gt;
    Animal species = new Frogsaur();&lt;br /&gt;
    species.talk(); // which method to invoke ???&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Due to the ambiguity caused by the diamond problem, it isn’t clear whether the runtime system should invoke Frog’s talk() method or Dinosaur talk() method.&lt;br /&gt;
&lt;br /&gt;
==Approaches==&lt;br /&gt;
Different programming languages have addressed the diamond problem in different ways.&lt;br /&gt;
&lt;br /&gt;
In Java, interfaces solve all these ambiguities caused by the diamond problem. Through interfaces, Java allows multiple inheritance of interface but not of implementation. Implementation, which includes instance variables and method implementations, is always singly inherited. As a result, confusion will never arise in Java over which inherited instance variable or method implementation to use.&lt;br /&gt;
&lt;br /&gt;
Ruby does not support multiple inheritance. Mixin provide a way which eliminates the need for multiple inheritance. Ruby has modules which are just like abstract classes&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/java/IandI/abstract.html Abstract Classes]&amp;lt;/ref&amp;gt; in Java. Modules can have different methods implemented in them. They cannot be instantiated like abstract classes. They cannot inherit from other modules or classes. Ruby classes can inherit from only one superclass but can have unlimited number of modules in them to exploit the usage of predefined implementations in these modules. This provides functionality similar to multiple inheritance avoiding any ambiguities.&lt;br /&gt;
&lt;br /&gt;
The below code in Ruby demonstrates two modules Frog and Dinosaur, each of which contain the talk method defined in them. The Frogsaur class ''includes'' these two methods and defines its own talk method. This example was chosen to exhibit on how Ruby resolves method calls at run time.&lt;br /&gt;
&lt;br /&gt;
  module Frog&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can croak&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  module Dinosaur&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can roar&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  class Frogsaur&lt;br /&gt;
      include Frog &lt;br /&gt;
      include Dinosaur&lt;br /&gt;
         def talk&lt;br /&gt;
             puts &amp;quot;I can roar like a dinosaur and croak like a frog&amp;quot;&lt;br /&gt;
         end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  fs = Frogsaur.new&lt;br /&gt;
  fs.talk         # -&amp;gt; I can roar like a dinosaur and croak like a frog&lt;br /&gt;
&lt;br /&gt;
When the method talk is called on the Frogsaur object, Ruby makes sure that the latest method defined in the hierarchy is chosen. Here in this example, the talk method in the Frogsaur class is defined the latest and hence “I can roar like a dinosaur and croak like a frog” is printed. If there was no method defined in the class, method from the Dinosaur is printed since it is next in the hierarchy specified by the include statements.&lt;br /&gt;
&lt;br /&gt;
=Comparison between Mixins and Interfaces=&lt;br /&gt;
&lt;br /&gt;
This is a general comparision: &lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, modules have the implementation of the methods. So all the classes which include the modules gets the same Implementation because  classes create a reference to these modules.&lt;br /&gt;
|In Java, all classes which implement the interfaces should provide implementation for each of the methods declared in the interface. This might duplicate the code if the two or more classes have similar functionality.&lt;br /&gt;
|-&lt;br /&gt;
| The size of the code is relatively smaller because the classes automatically get access to methods defined in the modules. Modules server as a central repository&lt;br /&gt;
| The size is relatively larger because a class implementing more than one interfaces has to provide implementation.&lt;br /&gt;
|-&lt;br /&gt;
| Having more modules in the classes can make code less readable. Ideally mixins are suitable for small teams having few modules. &lt;br /&gt;
| The code is more readable here as the implementation is provided to each method and can be found in place&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, a method inside a module can have Module name as qualifier. Hence it’s possible for a class to have inherit two or more modules which have same names.&lt;br /&gt;
| In Java, the class itself has to provide the implementation of the methods. Inheriting methods of same names from different interfaces will signal an error message.&lt;br /&gt;
|-&lt;br /&gt;
| Modules cannot be inherited and cannot form is-a hierarchy&lt;br /&gt;
| Interfaces can extend another interface and hence can form is-a hierarchy&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Drawbacks of Mixins and Interfaces==&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces are also limited to public methods and constants with no implementation.&lt;br /&gt;
&lt;br /&gt;
=Conclusion=&lt;br /&gt;
Although mixins have certain advantages over interfaces, they possess their own share of disadvantages. Mixins are generally used in small frameworks and interfaces , more than solving the problem of multiple inheritance provide polymorphism feature which makes object-oriented code more flexible and easy to modify and maintain.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=See Also=&lt;br /&gt;
1. http://ruby.about.com/od/beginningruby/a/mixin.html&amp;lt;br&amp;gt;&lt;br /&gt;
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ &amp;lt;br&amp;gt;&lt;br /&gt;
3. https://www.re-motion.org/blogs/team/2008/02/20/introducing-mixins-finally/ &amp;lt;br&amp;gt;&lt;br /&gt;
4. https://www.cs.washington.edu/education/courses/cse413/11sp/lectures/ruby_interfaces-etc.pdf &amp;lt;br&amp;gt;&lt;br /&gt;
5. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&amp;amp;printable=yes &amp;lt;br&amp;gt;&lt;br /&gt;
6. http://csis.pace.edu/~bergin/patterns/multipleinheritance.html&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=51568</id>
		<title>CSC/ECE 517 Fall 2011/ch2 2c ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=51568"/>
		<updated>2011-09-30T19:33:36Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Drawbacks of Mixins and Interfaces */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Mixins vs. Interfaces=&lt;br /&gt;
&lt;br /&gt;
=Introduction=&lt;br /&gt;
&lt;br /&gt;
In object oriented programming Mixins and Interfaces provide neat constructs to implement certain functionality and benefit from code re-usability. Understanding these constructs will benefit any programmer in designing any software with maximum polymorphic behavior and code re-usability. &lt;br /&gt;
&lt;br /&gt;
With the advent of object oriented languages, the designers of the language had to come up with the decision of whether or not to include the concept of multiple inheritance. Languages like C++ and Perl allow multiple inheritance whereas the designers of languages like C# and Java decided not to because of the problems associated with multiple inheritance&amp;lt;ref&amp;gt;[http://www.artima.com/intv/gosling13.html Inspiration for Interface]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
While [http://en.wikipedia.org/wiki/Java_%28programming_language%29 Java] like languages implemented interfaces to allow for [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism],languages like [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] opted not to implement multiple inheritance but to allow the code from one module be added into another class. &lt;br /&gt;
&lt;br /&gt;
Though both interfaces and Mixins simulate multiple inheritance and avoid the common pathologies associated with it , they have their own set of compromises. The below article tries to provide clarity on how this is achieved in each and also provides other distinctive features of Mixins and interfaces. &lt;br /&gt;
&lt;br /&gt;
===Interfaces===&lt;br /&gt;
In an object-oriented programming languages such as Java, C#, an interface&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/ Interfaces] &amp;lt;/ref&amp;gt; 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. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
&lt;br /&gt;
  public interface ParkingLot {&lt;br /&gt;
        boolean add(Car car, int slot);&lt;br /&gt;
        boolean remove(Car car);&lt;br /&gt;
        boolean findCar(Int number);&lt;br /&gt;
        int freeSlotsCount();&lt;br /&gt;
        int occupiedSlots();&lt;br /&gt;
        int parkingType();&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration);&lt;br /&gt;
        int findParkingSlot();&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
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. Interfaces provide an alternative  for languages like Java that does not allow multiple inheritance .&lt;br /&gt;
&lt;br /&gt;
In Java, a class can inherit from only one class but it can implement more than one interface. Therefore, objects can have multiple types: the type of their own class and the types of all the interfaces that they implement. This means that if a variable is declared to be the type of an interface, its value can reference any object that is instantiated from any class that implements the interface.&lt;br /&gt;
&lt;br /&gt;
==Mixins==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Modules are defined in Ruby using the ''module'' keyword.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;ref&amp;gt;[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Below is an example for modules and Mixins:&lt;br /&gt;
&lt;br /&gt;
The module ParkingSlot consists of the methods park and unpark&lt;br /&gt;
  &amp;lt;span style=&amp;quot;color:#4682B4&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingSlot&lt;br /&gt;
        def park&lt;br /&gt;
           #code to park the car&lt;br /&gt;
        end&lt;br /&gt;
        def unpark&lt;br /&gt;
           #code to unpark the car&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/span&amp;gt;&lt;br /&gt;
The module ParkingMeter consists of the methods calculate and printreceipt&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#F4A460&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingMeter&lt;br /&gt;
        def calculate&lt;br /&gt;
           #code to calculate the parking fee&lt;br /&gt;
        end&lt;br /&gt;
        def printreceipt&lt;br /&gt;
           #code to print the receipt&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
When a class ''includes'' a module via include Module Name, all the methods on that module become instance methods on the class.&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#6B8E23&amp;quot;&amp;gt;&lt;br /&gt;
  class Parking&lt;br /&gt;
       include ParkingSlot&lt;br /&gt;
       include ParkingMeter&lt;br /&gt;
       def printcardetails&lt;br /&gt;
           #code to print the details and type of car&lt;br /&gt;
       end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
  p=Parking.new   &lt;br /&gt;
  p.park            # -&amp;gt; Method park from module ParkingSlot&lt;br /&gt;
  p.unpark          # -&amp;gt; Method unpark from module ParkingSlot&lt;br /&gt;
  p.calculate       # -&amp;gt; Method calculate from module ParkingMeter&lt;br /&gt;
  p.printreceipt    # -&amp;gt; Method printreceipt from module ParkingMeter&lt;br /&gt;
  p.printcardetails # -&amp;gt; Calls printCarDetails from class&lt;br /&gt;
&lt;br /&gt;
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''.&lt;br /&gt;
&lt;br /&gt;
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 [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Subclasses_and_superclasses superclass].&lt;br /&gt;
&lt;br /&gt;
[[Image:ParkingLot.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
==Supported Languages==&lt;br /&gt;
The following table shows support for Mixins and Interfaces by most commonly used languages.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Languages&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| Ruby&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Java&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Python&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Smalltalk&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Perl&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| C#&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=Multiple Inheritance=&lt;br /&gt;
[http://en.wikipedia.org/wiki/Multiple_inheritance Multiple Inheritance] refers to a feature in some [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented programming] languages in which a class can inherit behaviors from more than one superclass. This contrasts with single inheritance in which a class can inherit behavior from at most one superclass. &lt;br /&gt;
Though Multiple Inheritance provides its own advantages of improved modularity and ease of reuse of code in certain applications, it has its own set of disadvantages which sometimes outweigh the possible advantages.&lt;br /&gt;
&lt;br /&gt;
==Diamond Problem==&lt;br /&gt;
This section describes the well know “Diamond Problem”&amp;lt;ref&amp;gt;[http://www.artima.com/designtechniques/interfaces2.html Diamond Problem] &amp;lt;/ref&amp;gt; associated with multiple Inheritance and the succeeding sections describe how Mixins and interfaces can be used to overcome this problem.&lt;br /&gt;
The diamond problem is the ambiguity that can occur when a class inherits from two different classes that both descend from a common superclass. For example, consider a scenario where one decides to combine the Frog and Dinosaur species which both are inherited from the Animal class. The talk() method in the Animal class is abstract and both Frog and Dinosaur needs to implement this method.&lt;br /&gt;
&lt;br /&gt;
Lets say both Frog and Dinosaur implement the talk method like this:&lt;br /&gt;
&lt;br /&gt;
    public class Frog extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Frog, I can croak “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
and,&lt;br /&gt;
    public class Dinosaur extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Dinosaur, I can roar “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
[[Image:Diamond_problem.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
When the Frogsaur is created, it inherits from both Frog and Dinosaur. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    public class Frogsaur extends Frog, Dinosaur {&lt;br /&gt;
       // Note below syntax is used just for demonstration. However java might throw compile time error.&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
The real problem occurs when someone tries to invoke talk() method on a Frogsaur object from the Animal reference.&lt;br /&gt;
    &lt;br /&gt;
    Animal species = new Frogsaur();&lt;br /&gt;
    species.talk(); // which method to invoke ???&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Due to the ambiguity caused by the diamond problem, it isn’t clear whether the runtime system should invoke Frog’s talk() method or Dinosaur talk() method.&lt;br /&gt;
&lt;br /&gt;
==Approaches==&lt;br /&gt;
Different programming languages have addressed the diamond problem in different ways.&lt;br /&gt;
&lt;br /&gt;
In Java, interfaces solve all these ambiguities caused by the diamond problem. Through interfaces, Java allows multiple inheritance of interface but not of implementation. Implementation, which includes instance variables and method implementations, is always singly inherited. As a result, confusion will never arise in Java over which inherited instance variable or method implementation to use.&lt;br /&gt;
&lt;br /&gt;
Ruby does not support multiple inheritance. Mixin provide a way which eliminates the need for multiple inheritance. Ruby has modules which are just like abstract classes&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/java/IandI/abstract.html Abstract Classes]&amp;lt;/ref&amp;gt; in Java. Modules can have different methods implemented in them. They cannot be instantiated like abstract classes. They cannot inherit from other modules or classes. Ruby classes can inherit from only one superclass but can have unlimited number of modules in them to exploit the usage of predefined implementations in these modules. This provides functionality similar to multiple inheritance avoiding any ambiguities.&lt;br /&gt;
&lt;br /&gt;
The below code in Ruby demonstrates two modules Frog and Dinosaur, each of which contain the talk method defined in them. The Frogsaur class ''includes'' these two methods and defines its own talk method. This example was chosen to exhibit on how Ruby resolves method calls at run time.&lt;br /&gt;
&lt;br /&gt;
  module Frog&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can croak&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  module Dinosaur&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can roar&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  class Frogsaur&lt;br /&gt;
      include Frog &lt;br /&gt;
      include Dinosaur&lt;br /&gt;
         def talk&lt;br /&gt;
             puts &amp;quot;I can roar like a dinosaur and croak like a frog&amp;quot;&lt;br /&gt;
         end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  fs = Frogsaur.new&lt;br /&gt;
  fs.talk         # -&amp;gt; I can roar like a dinosaur and croak like a frog&lt;br /&gt;
&lt;br /&gt;
When the method talk is called on the Frogsaur object, Ruby makes sure that the latest method defined in the hierarchy is chosen. Here in this example, the talk method in the Frogsaur class is defined the latest and hence “I can roar like a dinosaur and croak like a frog” is printed. If there was no method defined in the class, method from the Dinosaur is printed since it is next in the hierarchy specified by the include statements.&lt;br /&gt;
&lt;br /&gt;
=Comparison between Mixins and Interfaces=&lt;br /&gt;
&lt;br /&gt;
This is a general comparision: &lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, modules have the implementation of the methods. So all the classes which include the modules gets the same Implementation because  classes create a reference to these modules.&lt;br /&gt;
|In Java, all classes which implement the interfaces should provide implementation for each of the methods declared in the interface. This might duplicate the code if the two or more classes have similar functionality.&lt;br /&gt;
|-&lt;br /&gt;
| The size of the code is relatively smaller because the classes automatically get access to methods defined in the modules. Modules server as a central repository&lt;br /&gt;
| The size is relatively larger because a class implementing more than one interfaces has to provide implementation.&lt;br /&gt;
|-&lt;br /&gt;
| Having more modules in the classes can make code less readable. Ideally mixins are suitable for small teams having few modules. &lt;br /&gt;
| The code is more readable here as the implementation is provided to each method and can be found in place&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, a method inside a module can have Module name as qualifier. Hence it’s possible for a class to have inherit two or more modules which have same names.&lt;br /&gt;
| In Java, the class itself has to provide the implementation of the methods. Inheriting methods of same names from different interfaces will signal an error message.&lt;br /&gt;
|-&lt;br /&gt;
| Modules cannot be inherited and cannot form is-a hierarchy&lt;br /&gt;
| Interfaces can extend another interface and hence can form is-a hierarchy&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Drawbacks of Mixins and Interfaces==&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces are also limited to public methods and constants with no implementation.&lt;br /&gt;
&lt;br /&gt;
=Conclusion=&lt;br /&gt;
Although mixins have certain advantages over interfaces, they possess their own share of disadvantages. Mixins are generally used in small frameworks and interfaces , more than solving the problem of multiple inheritance provide polymorphism feature which makes object-oriented code more flexible and easy to modify and maintain.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=See Also=&lt;br /&gt;
1. http://ruby.about.com/od/beginningruby/a/mixin.html&amp;lt;br&amp;gt;&lt;br /&gt;
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ &amp;lt;br&amp;gt;&lt;br /&gt;
3. https://www.re-motion.org/blogs/team/2008/02/20/introducing-mixins-finally/ &amp;lt;br&amp;gt;&lt;br /&gt;
4. https://www.cs.washington.edu/education/courses/cse413/11sp/lectures/ruby_interfaces-etc.pdf &amp;lt;br&amp;gt;&lt;br /&gt;
5. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&amp;amp;printable=yes &amp;lt;br&amp;gt;&lt;br /&gt;
6. http://csis.pace.edu/~bergin/patterns/multipleinheritance.html&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=50266</id>
		<title>CSC/ECE 517 Fall 2011/ch2 2c ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=50266"/>
		<updated>2011-09-22T06:03:32Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Mixins vs. Interfaces=&lt;br /&gt;
&lt;br /&gt;
=Introduction=&lt;br /&gt;
&lt;br /&gt;
Mixins and Interfaces provide neat constructs in object-oriented languages to implement certain functionality and benefit from code reusability. Understanding these constructs will benefit any programmer in designing any software with maximum polymorphic behavior and code resuability. &lt;br /&gt;
&lt;br /&gt;
With the advent of object oriented languages, the designers of the language had to come up with the decision of whether or not to include the concept of multiple inheritance. Languages like C++ and Perl allow multiple inheritance whereas the designers of languages like C# and Java decided not to because of the problems associated with multiple inheritance&amp;lt;ref&amp;gt;[http://www.artima.com/intv/gosling13.html Inspiration for Interface]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
While [http://en.wikipedia.org/wiki/Java_%28programming_language%29 Java] like languages implemented interfaces to allow for [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism],languages like [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] opted not to implement multiple inheritance but to allow the code from one module be added into another class. &lt;br /&gt;
&lt;br /&gt;
Though both interfaces and Mixins simulate multiple inheritance and avoid the common pathologies associated with it , they have their own set of compromises. The below article tries to provide clarity on how this is achieved in each and also provides other distinctive features of Mixins and interfaces. &lt;br /&gt;
&lt;br /&gt;
===Interfaces===&lt;br /&gt;
In an object-oriented programming languages such as Java, C#, an interface&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/ Interfaces] &amp;lt;/ref&amp;gt; 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. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
&lt;br /&gt;
  public interface ParkingLot {&lt;br /&gt;
        boolean add(Car car, int slot);&lt;br /&gt;
        boolean remove(Car car);&lt;br /&gt;
        boolean findCar(Int number);&lt;br /&gt;
        int freeSlotsCount();&lt;br /&gt;
        int occupiedSlots();&lt;br /&gt;
        int parkingType();&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration);&lt;br /&gt;
        int findParkingSlot();&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
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. Interfaces provide an alternative  for languages like Java that does not allow multiple inheritance .&lt;br /&gt;
&lt;br /&gt;
In Java, a class can inherit from only one class but it can implement more than one interface. Therefore, objects can have multiple types: the type of their own class and the types of all the interfaces that they implement. This means that if a variable is declared to be the type of an interface, its value can reference any object that is instantiated from any class that implements the interface.&lt;br /&gt;
&lt;br /&gt;
==Mixins==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Modules are defined in Ruby using the ''module'' keyword.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;ref&amp;gt;[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Below is an example for modules and Mixins:&lt;br /&gt;
&lt;br /&gt;
The module ParkingSlot consists of the methods park and unpark&lt;br /&gt;
  &amp;lt;span style=&amp;quot;color:#4682B4&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingSlot&lt;br /&gt;
        def park&lt;br /&gt;
           #code to park the car&lt;br /&gt;
        end&lt;br /&gt;
        def unpark&lt;br /&gt;
           #code to unpark the car&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/span&amp;gt;&lt;br /&gt;
The module ParkingMeter consists of the methods calculate and printreceipt&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#F4A460&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingMeter&lt;br /&gt;
        def calculate&lt;br /&gt;
           #code to calculate the parking fee&lt;br /&gt;
        end&lt;br /&gt;
        def printreceipt&lt;br /&gt;
           #code to print the receipt&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
When a class ''includes'' a module via include Module Name, all the methods on that module become instance methods on the class.&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#6B8E23&amp;quot;&amp;gt;&lt;br /&gt;
  class Parking&lt;br /&gt;
       include ParkingSlot&lt;br /&gt;
       include ParkingMeter&lt;br /&gt;
       def printcardetails&lt;br /&gt;
           #code to print the details and type of car&lt;br /&gt;
       end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
  p=Parking.new   &lt;br /&gt;
  p.park            # -&amp;gt; Method park from module ParkingSlot&lt;br /&gt;
  p.unpark          # -&amp;gt; Method unpark from module ParkingSlot&lt;br /&gt;
  p.calculate       # -&amp;gt; Method calculate from module ParkingMeter&lt;br /&gt;
  p.printreceipt    # -&amp;gt; Method printreceipt from module ParkingMeter&lt;br /&gt;
  p.printcardetails # -&amp;gt; Calls printCarDetails from class&lt;br /&gt;
&lt;br /&gt;
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''.&lt;br /&gt;
&lt;br /&gt;
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 [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Subclasses_and_superclasses superclass].&lt;br /&gt;
&lt;br /&gt;
[[Image:ParkingLot.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
==Supported Languages==&lt;br /&gt;
The following table shows support for Mixins and Interfaces by most commonly used languages.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Languages&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| Ruby&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Java&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Python&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Smalltalk&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Perl&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| C#&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=Multiple Inheritance=&lt;br /&gt;
[http://en.wikipedia.org/wiki/Multiple_inheritance Multiple Inheritance] refers to a feature in some [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented programming] languages in which a class can inherit behaviors from more than one superclass. This contrasts with single inheritance in which a class can inherit behavior from at most one superclass. &lt;br /&gt;
Though Multiple Inheritance provides its own advantages of improved modularity and ease of reuse of code in certain applications, it has its own set of disadvantages which sometimes outweigh the possible advantages.&lt;br /&gt;
&lt;br /&gt;
==Diamond Problem==&lt;br /&gt;
This section describes the well know “Diamond Problem”&amp;lt;ref&amp;gt;[http://www.artima.com/designtechniques/interfaces2.html Diamond Problem] &amp;lt;/ref&amp;gt; associated with multiple Inheritance and the succeeding sections describe how Mixins and interfaces can be used to overcome this problem.&lt;br /&gt;
The diamond problem is the ambiguity that can occur when a class inherits from two different classes that both descend from a common superclass. For example, consider a scenario where one decides to combine the Frog and Dinosaur species which both are inherited from the Animal class. The talk() method in the Animal class is abstract and both Frog and Dinosaur needs to implement this method.&lt;br /&gt;
&lt;br /&gt;
Lets say both Frog and Dinosaur implement the talk method like this:&lt;br /&gt;
&lt;br /&gt;
    public class Frog extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Frog, I can croak “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
and,&lt;br /&gt;
    public class Dinosaur extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Dinosaur, I can roar “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
[[Image:Diamond_problem.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
When the Frogsaur is created, it inherits from both Frog and Dinosaur. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    public class Frogsaur extends Frog, Dinosaur {&lt;br /&gt;
       // Note below syntax is used just for demonstration. However java might throw compile time error.&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
The real problem occurs when someone tries to invoke talk() method on a Frogsaur object from the Animal reference.&lt;br /&gt;
    &lt;br /&gt;
    Animal species = new Frogsaur();&lt;br /&gt;
    species.talk(); // which method to invoke ???&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Due to the ambiguity caused by the diamond problem, it isn’t clear whether the runtime system should invoke Frog’s talk() method or Dinosaur talk() method.&lt;br /&gt;
&lt;br /&gt;
==Approaches==&lt;br /&gt;
Different programming languages have addressed the diamond problem in different ways.&lt;br /&gt;
&lt;br /&gt;
In Java, interfaces solve all these ambiguities caused by the diamond problem. Through interfaces, Java allows multiple inheritance of interface but not of implementation. Implementation, which includes instance variables and method implementations, is always singly inherited. As a result, confusion will never arise in Java over which inherited instance variable or method implementation to use.&lt;br /&gt;
&lt;br /&gt;
Ruby does not support multiple inheritance. Mixin provide a way which eliminates the need for multiple inheritance. Ruby has modules which are just like abstract classes&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/java/IandI/abstract.html Abstract Classes]&amp;lt;/ref&amp;gt; in Java. Modules can have different methods implemented in them. They cannot be instantiated like abstract classes. They cannot inherit from other modules or classes. Ruby classes can inherit from only one superclass but can have unlimited number of modules in them to exploit the usage of predefined implementations in these modules. This provides functionality similar to multiple inheritance avoiding any ambiguities.&lt;br /&gt;
&lt;br /&gt;
The below code in Ruby demonstrates two modules Frog and Dinosaur, each of which contain the talk method defined in them. The Frogsaur class ''includes'' these two methods and defines its own talk method. This example was chosen to exhibit on how Ruby resolves method calls at run time.&lt;br /&gt;
&lt;br /&gt;
  module Frog&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can croak&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  module Dinosaur&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can roar&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  class Frogsaur&lt;br /&gt;
      include Frog &lt;br /&gt;
      include Dinosaur&lt;br /&gt;
         def talk&lt;br /&gt;
             puts &amp;quot;I can roar like a dinosaur and croak like a frog&amp;quot;&lt;br /&gt;
         end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  fs = Frogsaur.new&lt;br /&gt;
  fs.talk         # -&amp;gt; I can roar like a dinosaur and croak like a frog&lt;br /&gt;
&lt;br /&gt;
When the method talk is called on the Frogsaur object, Ruby makes sure that the latest method defined in the hierarchy is chosen. Here in this example, the talk method in the Frogsaur class is defined the latest and hence “I can roar like a dinosaur and croak like a frog” is printed. If there was no method defined in the class, method from the Dinosaur is printed since it is next in the hierarchy specified by the include statements.&lt;br /&gt;
&lt;br /&gt;
=Comparison between Mixins and Interfaces=&lt;br /&gt;
&lt;br /&gt;
This is a general comparision: &lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, modules have the implementation of the methods. So all the classes which include the modules gets the same Implementation because  classes create a reference to these modules.&lt;br /&gt;
|In Java, all classes which implement the interfaces should provide implementation for each of the methods declared in the interface. This might duplicate the code if the two or more classes have similar functionality.&lt;br /&gt;
|-&lt;br /&gt;
| The size of the code is relatively smaller because the classes automatically get access to methods defined in the modules. Modules server as a central repository&lt;br /&gt;
| The size is relatively larger because a class implementing more than one interfaces has to provide implementation.&lt;br /&gt;
|-&lt;br /&gt;
| Having more modules in the classes can make code less readable. Ideally mixins are suitable for small teams having few modules. &lt;br /&gt;
| The code is more readable here as the implementation is provided to each method and can be found in place&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, a method inside a module can have Module name as qualifier. Hence it’s possible for a class to have inherit two or more modules which have same names.&lt;br /&gt;
| In Java, the class itself has to provide the implementation of the methods. Inheriting methods of same names from different interfaces will signal an error message.&lt;br /&gt;
|-&lt;br /&gt;
| Modules cannot be inherited and cannot form is-a hierarchy&lt;br /&gt;
| Interfaces can extend another interface and hence can form is-a hierarchy&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Drawbacks of Mixins and Interfaces==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces are also limited to public methods and constants with no implementation.&lt;br /&gt;
&lt;br /&gt;
=Conclusion=&lt;br /&gt;
Although mixins have certain advantages over interfaces, they possess their own share of disadvantages. Mixins are generally used in small frameworks and interfaces , more than solving the problem of multiple inheritance provide polymorphism feature which makes object-oriented code more flexible and easy to modify and maintain.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=See Also=&lt;br /&gt;
1. http://ruby.about.com/od/beginningruby/a/mixin.html&amp;lt;br&amp;gt;&lt;br /&gt;
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ &amp;lt;br&amp;gt;&lt;br /&gt;
3. https://www.re-motion.org/blogs/team/2008/02/20/introducing-mixins-finally/ &amp;lt;br&amp;gt;&lt;br /&gt;
4. https://www.cs.washington.edu/education/courses/cse413/11sp/lectures/ruby_interfaces-etc.pdf &amp;lt;br&amp;gt;&lt;br /&gt;
5. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&amp;amp;printable=yes &amp;lt;br&amp;gt;&lt;br /&gt;
6. http://csis.pace.edu/~bergin/patterns/multipleinheritance.html&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=50265</id>
		<title>CSC/ECE 517 Fall 2011/ch2 2c ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=50265"/>
		<updated>2011-09-22T05:59:51Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Mixins vs. Interfaces=&lt;br /&gt;
&lt;br /&gt;
=Introduction=&lt;br /&gt;
&lt;br /&gt;
Mixins and Interfaces provide neat constructs in object-oriented languages to implement certain functionality and benefit from code reusability. Understanding these constructs will benefit any programmer in designing any software with maximum polymorphic behavior and code resuability. &lt;br /&gt;
&lt;br /&gt;
With the advent of object oriented languages, the designers of the language had to come up with the decision of whether or not to include the concept of multiple inheritance. Languages like C++ and Perl allow multiple inheritance whereas the designers of languages like C# and Java decided not to because of the problems associated with multiple inheritance.&lt;br /&gt;
&lt;br /&gt;
While [http://en.wikipedia.org/wiki/Java_%28programming_language%29 Java] like languages implemented interfaces to allow for [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism],languages like [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] opted not to implement multiple inheritance but to allow the code from one module be added into another class. &lt;br /&gt;
&lt;br /&gt;
Though both interfaces and Mixins simulate multiple inheritance and avoid the common pathologies associated with it , they have their own set of compromises. The below article tries to provide clarity on how this is achieved in each and also provides other distinctive features of Mixins and interfaces. &lt;br /&gt;
&lt;br /&gt;
===Interfaces===&lt;br /&gt;
In an object-oriented programming languages such as Java, C#, an interface&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/ Interfaces] &amp;lt;/ref&amp;gt; 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. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
&lt;br /&gt;
  public interface ParkingLot {&lt;br /&gt;
        boolean add(Car car, int slot);&lt;br /&gt;
        boolean remove(Car car);&lt;br /&gt;
        boolean findCar(Int number);&lt;br /&gt;
        int freeSlotsCount();&lt;br /&gt;
        int occupiedSlots();&lt;br /&gt;
        int parkingType();&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration);&lt;br /&gt;
        int findParkingSlot();&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
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. Interfaces provide an alternative  for languages like Java that does not allow multiple inheritance .&lt;br /&gt;
&lt;br /&gt;
In Java, a class can inherit from only one class but it can implement more than one interface. Therefore, objects can have multiple types: the type of their own class and the types of all the interfaces that they implement. This means that if a variable is declared to be the type of an interface, its value can reference any object that is instantiated from any class that implements the interface.&lt;br /&gt;
&lt;br /&gt;
==Mixins==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Modules are defined in Ruby using the ''module'' keyword.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;ref&amp;gt;[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Below is an example for modules and Mixins:&lt;br /&gt;
&lt;br /&gt;
The module ParkingSlot consists of the methods park and unpark&lt;br /&gt;
  &amp;lt;span style=&amp;quot;color:#4682B4&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingSlot&lt;br /&gt;
        def park&lt;br /&gt;
           #code to park the car&lt;br /&gt;
        end&lt;br /&gt;
        def unpark&lt;br /&gt;
           #code to unpark the car&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/span&amp;gt;&lt;br /&gt;
The module ParkingMeter consists of the methods calculate and printreceipt&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#F4A460&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingMeter&lt;br /&gt;
        def calculate&lt;br /&gt;
           #code to calculate the parking fee&lt;br /&gt;
        end&lt;br /&gt;
        def printreceipt&lt;br /&gt;
           #code to print the receipt&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
When a class ''includes'' a module via include Module Name, all the methods on that module become instance methods on the class.&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#6B8E23&amp;quot;&amp;gt;&lt;br /&gt;
  class Parking&lt;br /&gt;
       include ParkingSlot&lt;br /&gt;
       include ParkingMeter&lt;br /&gt;
       def printcardetails&lt;br /&gt;
           #code to print the details and type of car&lt;br /&gt;
       end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
  p=Parking.new   &lt;br /&gt;
  p.park            # -&amp;gt; Method park from module ParkingSlot&lt;br /&gt;
  p.unpark          # -&amp;gt; Method unpark from module ParkingSlot&lt;br /&gt;
  p.calculate       # -&amp;gt; Method calculate from module ParkingMeter&lt;br /&gt;
  p.printreceipt    # -&amp;gt; Method printreceipt from module ParkingMeter&lt;br /&gt;
  p.printcardetails # -&amp;gt; Calls printCarDetails from class&lt;br /&gt;
&lt;br /&gt;
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''.&lt;br /&gt;
&lt;br /&gt;
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 [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Subclasses_and_superclasses superclass].&lt;br /&gt;
&lt;br /&gt;
[[Image:ParkingLot.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
==Supported Languages==&lt;br /&gt;
The following table shows support for Mixins and Interfaces by most commonly used languages.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Languages&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| Ruby&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Java&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Python&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Smalltalk&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Perl&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| C#&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=Multiple Inheritance=&lt;br /&gt;
[http://en.wikipedia.org/wiki/Multiple_inheritance Multiple Inheritance] refers to a feature in some [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented programming] languages in which a class can inherit behaviors from more than one superclass. This contrasts with single inheritance in which a class can inherit behavior from at most one superclass. &lt;br /&gt;
Though Multiple Inheritance provides its own advantages of improved modularity and ease of reuse of code in certain applications, it has its own set of disadvantages which sometimes outweigh the possible advantages.&lt;br /&gt;
&lt;br /&gt;
==Diamond Problem==&lt;br /&gt;
This section describes the well know “Diamond Problem”&amp;lt;ref&amp;gt;[http://www.artima.com/designtechniques/interfaces2.html Diamond Problem] &amp;lt;/ref&amp;gt; associated with multiple Inheritance and the succeeding sections describe how Mixins and interfaces can be used to overcome this problem.&lt;br /&gt;
The diamond problem is the ambiguity that can occur when a class inherits from two different classes that both descend from a common superclass. For example, consider a scenario where one decides to combine the Frog and Dinosaur species which both are inherited from the Animal class. The talk() method in the Animal class is abstract and both Frog and Dinosaur needs to implement this method.&lt;br /&gt;
&lt;br /&gt;
Lets say both Frog and Dinosaur implement the talk method like this:&lt;br /&gt;
&lt;br /&gt;
    public class Frog extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Frog, I can croak “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
and,&lt;br /&gt;
    public class Dinosaur extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Dinosaur, I can roar “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
[[Image:Diamond_problem.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
When the Frogsaur is created, it inherits from both Frog and Dinosaur. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    public class Frogsaur extends Frog, Dinosaur {&lt;br /&gt;
       // Note below syntax is used just for demonstration. However java might throw compile time error.&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
The real problem occurs when someone tries to invoke talk() method on a Frogsaur object from the Animal reference.&lt;br /&gt;
    &lt;br /&gt;
    Animal species = new Frogsaur();&lt;br /&gt;
    species.talk(); // which method to invoke ???&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Due to the ambiguity caused by the diamond problem, it isn’t clear whether the runtime system should invoke Frog’s talk() method or Dinosaur talk() method.&lt;br /&gt;
&lt;br /&gt;
==Approaches==&lt;br /&gt;
Different programming languages have addressed the diamond problem in different ways.&lt;br /&gt;
&lt;br /&gt;
In Java, interfaces solve all these ambiguities caused by the diamond problem. Through interfaces, Java allows multiple inheritance of interface but not of implementation. Implementation, which includes instance variables and method implementations, is always singly inherited. As a result, confusion will never arise in Java over which inherited instance variable or method implementation to use.&lt;br /&gt;
&lt;br /&gt;
Ruby does not support multiple inheritance. Mixin provide a way which eliminates the need for multiple inheritance. Ruby has modules which are just like abstract classes&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/java/IandI/abstract.html Abstract Classes]&amp;lt;/ref&amp;gt; in Java. Modules can have different methods implemented in them. They cannot be instantiated like abstract classes. They cannot inherit from other modules or classes. Ruby classes can inherit from only one superclass but can have unlimited number of modules in them to exploit the usage of predefined implementations in these modules. This provides functionality similar to multiple inheritance avoiding any ambiguities.&lt;br /&gt;
&lt;br /&gt;
The below code in Ruby demonstrates two modules Frog and Dinosaur, each of which contain the talk method defined in them. The Frogsaur class ''includes'' these two methods and defines its own talk method. This example was chosen to exhibit on how Ruby resolves method calls at run time.&lt;br /&gt;
&lt;br /&gt;
  module Frog&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can croak&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  module Dinosaur&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can roar&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  class Frogsaur&lt;br /&gt;
      include Frog &lt;br /&gt;
      include Dinosaur&lt;br /&gt;
         def talk&lt;br /&gt;
             puts &amp;quot;I can roar like a dinosaur and croak like a frog&amp;quot;&lt;br /&gt;
         end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  fs = Frogsaur.new&lt;br /&gt;
  fs.talk         # -&amp;gt; I can roar like a dinosaur and croak like a frog&lt;br /&gt;
&lt;br /&gt;
When the method talk is called on the Frogsaur object, Ruby makes sure that the latest method defined in the hierarchy is chosen. Here in this example, the talk method in the Frogsaur class is defined the latest and hence “I can roar like a dinosaur and croak like a frog” is printed. If there was no method defined in the class, method from the Dinosaur is printed since it is next in the hierarchy specified by the include statements.&lt;br /&gt;
&lt;br /&gt;
=Comparison between Mixins and Interfaces=&lt;br /&gt;
&lt;br /&gt;
This is a general comparision: &lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, modules have the implementation of the methods. So all the classes which include the modules gets the same Implementation because  classes create a reference to these modules.&lt;br /&gt;
|In Java, all classes which implement the interfaces should provide implementation for each of the methods declared in the interface. This might duplicate the code if the two or more classes have similar functionality.&lt;br /&gt;
|-&lt;br /&gt;
| The size of the code is relatively smaller because the classes automatically get access to methods defined in the modules. Modules server as a central repository&lt;br /&gt;
| The size is relatively larger because a class implementing more than one interfaces has to provide implementation.&lt;br /&gt;
|-&lt;br /&gt;
| Having more modules in the classes can make code less readable. Ideally mixins are suitable for small teams having few modules. &lt;br /&gt;
| The code is more readable here as the implementation is provided to each method and can be found in place&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, a method inside a module can have Module name as qualifier. Hence it’s possible for a class to have inherit two or more modules which have same names.&lt;br /&gt;
| In Java, the class itself has to provide the implementation of the methods. Inheriting methods of same names from different interfaces will signal an error message.&lt;br /&gt;
|-&lt;br /&gt;
| Modules cannot be inherited and cannot form is-a hierarchy&lt;br /&gt;
| Interfaces can extend another interface and hence can form is-a hierarchy&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Drawbacks of Mixins and Interfaces==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces are also limited to public methods and constants with no implementation.&lt;br /&gt;
&lt;br /&gt;
=Conclusion=&lt;br /&gt;
Although mixins have certain advantages over interfaces, they possess their own share of disadvantages. Mixins are generally used in small frameworks and interfaces , more than solving the problem of multiple inheritance provide polymorphism feature which makes object-oriented code more flexible and easy to modify and maintain.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=See Also=&lt;br /&gt;
1. http://ruby.about.com/od/beginningruby/a/mixin.html&amp;lt;br&amp;gt;&lt;br /&gt;
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ &amp;lt;br&amp;gt;&lt;br /&gt;
3. https://www.re-motion.org/blogs/team/2008/02/20/introducing-mixins-finally/ &amp;lt;br&amp;gt;&lt;br /&gt;
4. https://www.cs.washington.edu/education/courses/cse413/11sp/lectures/ruby_interfaces-etc.pdf &amp;lt;br&amp;gt;&lt;br /&gt;
5. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&amp;amp;printable=yes &amp;lt;br&amp;gt;&lt;br /&gt;
6. http://csis.pace.edu/~bergin/patterns/multipleinheritance.html&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=50203</id>
		<title>CSC/ECE 517 Fall 2011/ch2 2c ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=50203"/>
		<updated>2011-09-22T03:39:32Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Approaches */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Mixins vs. Interfaces=&lt;br /&gt;
&lt;br /&gt;
=Introduction=&lt;br /&gt;
With the advent of object oriented languages, the designers of the language had to come up with the decision of whether or not to include the concept of multiple inheritance. Languages like C++ and Perl allow multiple inheritance whereas the designers of languages like C# and Java decided not to . &lt;br /&gt;
&lt;br /&gt;
While Java like languages implemented interfaces to allow for [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism],languages like Ruby opted not to implement multiple inheritance but to allow the code from one module be added into another class. &lt;br /&gt;
&lt;br /&gt;
Though both interfaces and Mixins simulate multiple inheritance and avoid the common pathologies associated with it , they have their own set of compromises. The below article tries to provide clarity on how this is achieved in each and also provides other distinctive features of Mixins and interfaces. &lt;br /&gt;
&lt;br /&gt;
===Interfaces===&lt;br /&gt;
In an object-oriented programming languages such as Java, C#, an interface&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/ Interfaces] &amp;lt;/ref&amp;gt; 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. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
&lt;br /&gt;
  public interface ParkingLot {&lt;br /&gt;
        boolean add(Car car, int slot);&lt;br /&gt;
        boolean remove(Car car);&lt;br /&gt;
        boolean findCar(Int number);&lt;br /&gt;
        int freeSlotsCount();&lt;br /&gt;
        int occupiedSlots();&lt;br /&gt;
        int parkingType();&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration);&lt;br /&gt;
        int findParkingSlot();&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
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. Interfaces provide an alternative  for languages like Java that does not allow multiple inheritance .&lt;br /&gt;
&lt;br /&gt;
In Java, a class can inherit from only one class but it can implement more than one interface. Therefore, objects can have multiple types: the type of their own class and the types of all the interfaces that they implement. This means that if a variable is declared to be the type of an interface, its value can reference any object that is instantiated from any class that implements the interface.&lt;br /&gt;
&lt;br /&gt;
==Mixins==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Modules are defined in Ruby using the ''module'' keyword.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;ref&amp;gt;[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Below is an example for modules and Mixins:&lt;br /&gt;
&lt;br /&gt;
The module ParkingSlot consists of the methods park and unpark&lt;br /&gt;
  &amp;lt;span style=&amp;quot;color:#4682B4&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingSlot&lt;br /&gt;
        def park&lt;br /&gt;
           #code to park the car&lt;br /&gt;
        end&lt;br /&gt;
        def unpark&lt;br /&gt;
           #code to unpark the car&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/span&amp;gt;&lt;br /&gt;
The module ParkingMeter consists of the methods calculate and printreceipt&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#F4A460&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingMeter&lt;br /&gt;
        def calculate&lt;br /&gt;
           #code to calculate the parking fee&lt;br /&gt;
        end&lt;br /&gt;
        def printreceipt&lt;br /&gt;
           #code to print the receipt&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
When a class ''includes'' a module via include Module Name, all the methods on that module become instance methods on the class.&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#6B8E23&amp;quot;&amp;gt;&lt;br /&gt;
  class Parking&lt;br /&gt;
       include ParkingSlot&lt;br /&gt;
       include ParkingMeter&lt;br /&gt;
       def printcardetails&lt;br /&gt;
           #code to print the details and type of car&lt;br /&gt;
       end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
  p=Parking.new   &lt;br /&gt;
  p.park            # -&amp;gt; Method park from module ParkingSlot&lt;br /&gt;
  p.unpark          # -&amp;gt; Method unpark from module ParkingSlot&lt;br /&gt;
  p.calculate       # -&amp;gt; Method calculate from module ParkingMeter&lt;br /&gt;
  p.printreceipt    # -&amp;gt; Method printreceipt from module ParkingMeter&lt;br /&gt;
  p.printcardetails # -&amp;gt; Calls printCarDetails from class&lt;br /&gt;
&lt;br /&gt;
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''.&lt;br /&gt;
&lt;br /&gt;
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 [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Subclasses_and_superclasses superclass].&lt;br /&gt;
&lt;br /&gt;
[[Image:ParkingLot.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
==Supported Languages==&lt;br /&gt;
The following table shows support for Mixins and Interfaces by most commonly used languages.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Languages&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| Ruby&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Java&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Python&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Smalltalk&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Perl&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| C#&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=Multiple Inheritance=&lt;br /&gt;
[http://en.wikipedia.org/wiki/Multiple_inheritance Multiple Inheritance] refers to a feature in some [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented programming] languages in which a class can inherit behaviors from more than one superclass. This contrasts with single inheritance in which a class can inherit behavior from at most one superclass. &lt;br /&gt;
Though Multiple Inheritance provides its own advantages of improved modularity and ease of reuse of code in certain applications, it has its own set of disadvantages which sometimes outweigh the possible advantages.&lt;br /&gt;
&lt;br /&gt;
==Diamond Problem==&lt;br /&gt;
This section describes the well know “Diamond Problem”&amp;lt;ref&amp;gt;[http://www.artima.com/designtechniques/interfaces2.html Diamond Problem] &amp;lt;/ref&amp;gt; associated with multiple Inheritance and the succeeding sections describe how Mixins and interfaces can be used to overcome this problem.&lt;br /&gt;
The diamond problem is the ambiguity that can occur when a class inherits from two different classes that both descend from a common superclass. For example, consider a scenario where one decides to combine the Frog and Dinosaur species which both are inherited from the Animal class. The talk() method in the Animal class is abstract and both Frog and Dinosaur needs to implement this method.&lt;br /&gt;
&lt;br /&gt;
Lets say both Frog and Dinosaur implement the talk method like this:&lt;br /&gt;
&lt;br /&gt;
    public class Frog extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Frog, I can croak “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
and,&lt;br /&gt;
    public class Dinosaur extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Dinosaur, I can roar “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
[[Image:Diamond_problem.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
When the Frogsaur is created, it inherits from both Frog and Dinosaur. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    public class Frogsaur extends Frog, Dinosaur {&lt;br /&gt;
       // Note below syntax is used just for demonstration. However java might throw compile time error.&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
The real problem occurs when someone tries to invoke talk() method on a Frogsaur object from the Animal reference.&lt;br /&gt;
    &lt;br /&gt;
    Animal species = new Frogsaur();&lt;br /&gt;
    species.talk(); // which method to invoke ???&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Due to the ambiguity caused by the diamond problem, it isn’t clear whether the runtime system should invoke Frog’s talk() method or Dinosaur talk() method.&lt;br /&gt;
&lt;br /&gt;
==Approaches==&lt;br /&gt;
Different programming languages have addressed the diamond problem in different ways.&lt;br /&gt;
&lt;br /&gt;
In Java, interfaces solve all these ambiguities caused by the diamond problem. Through interfaces, Java allows multiple inheritance of interface but not of implementation. Implementation, which includes instance variables and method implementations, is always singly inherited. As a result, confusion will never arise in Java over which inherited instance variable or method implementation to use.&lt;br /&gt;
&lt;br /&gt;
Ruby does not support multiple inheritance. Mixin provide a way which eliminates the need for multiple inheritance. Ruby has modules which are just like abstract classes&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/java/IandI/abstract.html Abstract Classes]&amp;lt;/ref&amp;gt; in Java. Modules can have different methods implemented in them. They cannot be instantiated like abstract classes. They cannot inherit from other modules or classes. Ruby classes can inherit from only one superclass but can have unlimited number of modules in them to exploit the usage of predefined implementations in these modules. This provides functionality similar to multiple inheritance avoiding any ambiguities.&lt;br /&gt;
&lt;br /&gt;
The below code in Ruby demonstrates two modules Frog and Dinosaur, each of which contain the talk method defined in them. The Frogsaur class ''includes'' these two methods and defines its own talk method. This example was chosen to exhibit on how Ruby resolves method calls at run time.&lt;br /&gt;
&lt;br /&gt;
  module Frog&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can croak&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  module Dinosaur&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can roar&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  class Frogsaur&lt;br /&gt;
      include Frog &lt;br /&gt;
      include Dinosaur&lt;br /&gt;
         def talk&lt;br /&gt;
             puts &amp;quot;I can roar like a dinosaur and croak like a frog&amp;quot;&lt;br /&gt;
         end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  fs = Frogsaur.new&lt;br /&gt;
  fs.talk         # -&amp;gt; I can roar like a dinosaur and croak like a frog&lt;br /&gt;
&lt;br /&gt;
When the method talk is called on the Frogsaur object, Ruby makes sure that the latest method defined in the hierarchy is chosen. Here in this example, the talk method in the Frogsaur class is defined the latest and hence “I can roar like a dinosaur and croak like a frog” is printed. If there was no method defined in the class, method from the Dinosaur is printed since it is next in the hierarchy specified by the include statements.&lt;br /&gt;
&lt;br /&gt;
=Comparison between Mixins and Interfaces=&lt;br /&gt;
&lt;br /&gt;
This is a general comparision: &lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, modules have the implementation of the methods. So all the classes which include the modules gets the same Implementation because  classes create a reference to these modules.&lt;br /&gt;
|In Java, all classes which implement the interfaces should provide implementation for each of the methods declared in the interface. This might duplicate the code if the two or more classes have similar functionality.&lt;br /&gt;
|-&lt;br /&gt;
| The size of the code is relatively smaller because the classes automatically get access to methods defined in the modules. Modules server as a central repository&lt;br /&gt;
| The size is relatively larger because a class implementing more than one interfaces has to provide implementation.&lt;br /&gt;
|-&lt;br /&gt;
| Having more modules in the classes can make code less readable. Ideally mixins are suitable for small teams having few modules. &lt;br /&gt;
| The code is more readable here as the implementation is provided to each method and can be found in place&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, a method inside a module can have Module name as qualifier. Hence it’s possible for a class to have inherit two or more modules which have same names.&lt;br /&gt;
| In Java, the class itself has to provide the implementation of the methods. Inheriting methods of same names from different interfaces will signal an error message.&lt;br /&gt;
|-&lt;br /&gt;
| Modules cannot be inherited and cannot form is-a hierarchy&lt;br /&gt;
| Interfaces can extend another interface and hence can form is-a hierarchy&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Drawbacks of Mixins and Interfaces==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces are also limited to public methods and constants with no implementation.&lt;br /&gt;
&lt;br /&gt;
=Conclusion=&lt;br /&gt;
Although mixins have certain advantages over interfaces, they possess their own share of disadvantages. Mixins are generally used in small frameworks and interfaces , more than solving the problem of multiple inheritance provide polymorphism feature which makes object-oriented code more flexible and easy to modify and maintain.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=See Also=&lt;br /&gt;
1. http://ruby.about.com/od/beginningruby/a/mixin.html&amp;lt;br&amp;gt;&lt;br /&gt;
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ &amp;lt;br&amp;gt;&lt;br /&gt;
3. https://www.re-motion.org/blogs/team/2008/02/20/introducing-mixins-finally/ &amp;lt;br&amp;gt;&lt;br /&gt;
4. https://www.cs.washington.edu/education/courses/cse413/11sp/lectures/ruby_interfaces-etc.pdf &amp;lt;br&amp;gt;&lt;br /&gt;
5. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&amp;amp;printable=yes &amp;lt;br&amp;gt;&lt;br /&gt;
6. http://csis.pace.edu/~bergin/patterns/multipleinheritance.html&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=50197</id>
		<title>CSC/ECE 517 Fall 2011/ch2 2c ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=50197"/>
		<updated>2011-09-22T03:31:39Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Comparison between Mixins and Interfaces */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Mixins vs. Interfaces=&lt;br /&gt;
&lt;br /&gt;
=Introduction=&lt;br /&gt;
With the advent of object oriented languages, the designers of the language had to come up with the decision of whether or not to include the concept of multiple inheritance. Languages like C++ and Perl allow multiple inheritance whereas the designers of languages like C# and Java decided not to . &lt;br /&gt;
&lt;br /&gt;
While Java like languages implemented interfaces to allow for [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism],languages like Ruby opted not to implement multiple inheritance but to allow the code from one module be added into another class. &lt;br /&gt;
&lt;br /&gt;
Though both interfaces and Mixins simulate multiple inheritance and avoid the common pathologies associated with it , they have their own set of compromises. The below article tries to provide clarity on how this is achieved in each and also provides other distinctive features of Mixins and interfaces. &lt;br /&gt;
&lt;br /&gt;
===Interfaces===&lt;br /&gt;
In an object-oriented programming languages such as Java, C#, an interface&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/ Interfaces] &amp;lt;/ref&amp;gt; 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. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
&lt;br /&gt;
  public interface ParkingLot {&lt;br /&gt;
        boolean add(Car car, int slot);&lt;br /&gt;
        boolean remove(Car car);&lt;br /&gt;
        boolean findCar(Int number);&lt;br /&gt;
        int freeSlotsCount();&lt;br /&gt;
        int occupiedSlots();&lt;br /&gt;
        int parkingType();&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration);&lt;br /&gt;
        int findParkingSlot();&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
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. Interfaces provide an alternative  for languages like Java that does not allow multiple inheritance .&lt;br /&gt;
&lt;br /&gt;
In Java, a class can inherit from only one class but it can implement more than one interface. Therefore, objects can have multiple types: the type of their own class and the types of all the interfaces that they implement. This means that if a variable is declared to be the type of an interface, its value can reference any object that is instantiated from any class that implements the interface.&lt;br /&gt;
&lt;br /&gt;
==Mixins==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Modules are defined in Ruby using the ''module'' keyword.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;ref&amp;gt;[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Below is an example for modules and Mixins:&lt;br /&gt;
&lt;br /&gt;
The module ParkingSlot consists of the methods park and unpark&lt;br /&gt;
  &amp;lt;span style=&amp;quot;color:#4682B4&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingSlot&lt;br /&gt;
        def park&lt;br /&gt;
           #code to park the car&lt;br /&gt;
        end&lt;br /&gt;
        def unpark&lt;br /&gt;
           #code to unpark the car&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/span&amp;gt;&lt;br /&gt;
The module ParkingMeter consists of the methods calculate and printreceipt&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#F4A460&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingMeter&lt;br /&gt;
        def calculate&lt;br /&gt;
           #code to calculate the parking fee&lt;br /&gt;
        end&lt;br /&gt;
        def printreceipt&lt;br /&gt;
           #code to print the receipt&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
When a class ''includes'' a module via include Module Name, all the methods on that module become instance methods on the class.&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#6B8E23&amp;quot;&amp;gt;&lt;br /&gt;
  class Parking&lt;br /&gt;
       include ParkingSlot&lt;br /&gt;
       include ParkingMeter&lt;br /&gt;
       def printcardetails&lt;br /&gt;
           #code to print the details and type of car&lt;br /&gt;
       end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
  p=Parking.new   &lt;br /&gt;
  p.park            # -&amp;gt; Method park from module ParkingSlot&lt;br /&gt;
  p.unpark          # -&amp;gt; Method unpark from module ParkingSlot&lt;br /&gt;
  p.calculate       # -&amp;gt; Method calculate from module ParkingMeter&lt;br /&gt;
  p.printreceipt    # -&amp;gt; Method printreceipt from module ParkingMeter&lt;br /&gt;
  p.printcardetails # -&amp;gt; Calls printCarDetails from class&lt;br /&gt;
&lt;br /&gt;
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''.&lt;br /&gt;
&lt;br /&gt;
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 [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Subclasses_and_superclasses superclass].&lt;br /&gt;
&lt;br /&gt;
[[Image:ParkingLot.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
==Supported Languages==&lt;br /&gt;
The following table shows support for Mixins and Interfaces by most commonly used languages.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Languages&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| Ruby&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Java&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Python&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Smalltalk&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Perl&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| C#&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=Multiple Inheritance=&lt;br /&gt;
[[Multiple Inheritance]] refers to a feature in some [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented programming] languages in which a class can inherit behaviors from more than one superclass. This contrasts with single inheritance in which a class can inherit behavior from at most one superclass. &lt;br /&gt;
Though Multiple Inheritance provides its own advantages of improved modularity and ease of reuse of code in certain applications, it has its own set of disadvantages which sometimes outweigh the possible advantages.&lt;br /&gt;
&lt;br /&gt;
==Diamond Problem==&lt;br /&gt;
This section describes the well know “Diamond Problem”&amp;lt;ref&amp;gt;[http://www.artima.com/designtechniques/interfaces2.html Diamond Problem] &amp;lt;/ref&amp;gt; associated with multiple Inheritance and the succeeding sections describe how Mixins and interfaces can be used to overcome this problem.&lt;br /&gt;
The diamond problem is the ambiguity that can occur when a class inherits from two different classes that both descend from a common superclass. For example, consider a scenario where one decides to combine the Frog and Dinosaur species which both are inherited from the Animal class. The talk() method in the Animal class is abstract and both Frog and Dinosaur needs to implement this method.&lt;br /&gt;
&lt;br /&gt;
Lets say both Frog and Dinosaur implement the talk method like this:&lt;br /&gt;
&lt;br /&gt;
    public class Frog extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Frog, I can croak “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
and,&lt;br /&gt;
    public class Dinosaur extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Dinosaur, I can roar “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
[[Image:Diamond_problem.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
When the Frogsaur is created, it inherits from both Frog and Dinosaur. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    public class Frogsaur extends Frog, Dinosaur {&lt;br /&gt;
       // Note below syntax is used just for demonstration. However java might throw compile time error.&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
The real problem occurs when someone tries to invoke talk() method on a Frogsaur object from the Animal reference.&lt;br /&gt;
    &lt;br /&gt;
    Animal species = new Frogsaur();&lt;br /&gt;
    species.talk(); // which method to invoke ???&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Due to the ambiguity caused by the diamond problem, it isn’t clear whether the runtime system should invoke Frog’s talk() method or Dinosaur talk() method.&lt;br /&gt;
&lt;br /&gt;
==Approaches==&lt;br /&gt;
Different programming languages have addressed the diamond problem in different ways.&lt;br /&gt;
&lt;br /&gt;
In Java, interfaces solve all these ambiguities caused by the diamond problem. Through interfaces, Java allows multiple inheritance of interface but not of implementation. Implementation, which includes instance variables and method implementations, is always singly inherited. As a result, confusion will never arise in Java over which inherited instance variable or method implementation to use.&lt;br /&gt;
&lt;br /&gt;
Ruby does not support multiple inheritance. Mixin provide a way which eliminates the need for multiple inheritance. Ruby has modules which are just like abstract classes in Java. Modules can have different methods implemented in them. They cannot be instantiated like abstract classes. They cannot inherit from other modules or classes. Ruby classes can inherit from only one superclass but can have unlimited number of modules in them to exploit the usage of predefined implementations in these modules. This provides functionality similar to multiple inheritance avoiding any ambiguities.&lt;br /&gt;
&lt;br /&gt;
The below code in Ruby demonstrates two modules Frog and Dinosaur, each of which contain the talk method defined in them. The Frogsaur class ''includes'' these two methods and defines its own talk method. This example was chosen to exhibit on how Ruby resolves method calls at run time.&lt;br /&gt;
&lt;br /&gt;
  module Frog&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can croak&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  module Dinosaur&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can roar&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  class Frogsaur&lt;br /&gt;
      include Frog &lt;br /&gt;
      include Dinosaur&lt;br /&gt;
         def talk&lt;br /&gt;
             puts &amp;quot;I can roar like a dinosaur and croak like a frog&amp;quot;&lt;br /&gt;
         end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  fs = Frogsaur.new&lt;br /&gt;
  fs.talk         # -&amp;gt; I can roar like a dinosaur and croak like a frog&lt;br /&gt;
&lt;br /&gt;
When the method talk is called on the Frogsaur object, Ruby makes sure that the latest method defined in the hierarchy is chosen. Here in this example, the talk method in the Frogsaur class is defined the latest and hence “I can roar like a dinosaur and croak like a frog” is printed. If there was no method defined in the class, method from the Dinosaur is printed since it is next in the hierarchy specified by the include statements.&lt;br /&gt;
&lt;br /&gt;
=Comparison between Mixins and Interfaces=&lt;br /&gt;
&lt;br /&gt;
This is a general comparision: &lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, modules have the implementation of the methods. So all the classes which include the modules gets the same Implementation because  classes create a reference to these modules.&lt;br /&gt;
|In Java, all classes which implement the interfaces should provide implementation for each of the methods declared in the interface. This might duplicate the code if the two or more classes have similar functionality.&lt;br /&gt;
|-&lt;br /&gt;
| The size of the code is relatively smaller because the classes automatically get access to methods defined in the modules. Modules server as a central repository&lt;br /&gt;
| The size is relatively larger because a class implementing more than one interfaces has to provide implementation.&lt;br /&gt;
|-&lt;br /&gt;
| Having more modules in the classes can make code less readable. Ideally mixins are suitable for small teams having few modules. &lt;br /&gt;
| The code is more readable here as the implementation is provided to each method and can be found in place&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, a method inside a module can have Module name as qualifier. Hence it’s possible for a class to have inherit two or more modules which have same names.&lt;br /&gt;
| In Java, the class itself has to provide the implementation of the methods. Inheriting methods of same names from different interfaces will signal an error message.&lt;br /&gt;
|-&lt;br /&gt;
| Modules cannot be inherited and cannot form is-a hierarchy&lt;br /&gt;
| Interfaces can extend another interface and hence can form is-a hierarchy&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Drawbacks of Mixins and Interfaces==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces are also limited to public methods and constants with no implementation.&lt;br /&gt;
&lt;br /&gt;
=Conclusion=&lt;br /&gt;
Although mixins have certain advantages over interfaces, they possess their own share of disadvantages. Mixins are generally used in small frameworks and interfaces , more than solving the problem of multiple inheritance provide polymorphism feature which makes object-oriented code more flexible and easy to modify and maintain.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=See Also=&lt;br /&gt;
1. http://ruby.about.com/od/beginningruby/a/mixin.html&amp;lt;br&amp;gt;&lt;br /&gt;
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ &amp;lt;br&amp;gt;&lt;br /&gt;
3. https://www.re-motion.org/blogs/team/2008/02/20/introducing-mixins-finally/ &amp;lt;br&amp;gt;&lt;br /&gt;
4. https://www.cs.washington.edu/education/courses/cse413/11sp/lectures/ruby_interfaces-etc.pdf &amp;lt;br&amp;gt;&lt;br /&gt;
5. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&amp;amp;printable=yes &amp;lt;br&amp;gt;&lt;br /&gt;
6. http://csis.pace.edu/~bergin/patterns/multipleinheritance.html&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=50196</id>
		<title>CSC/ECE 517 Fall 2011/ch2 2c ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=50196"/>
		<updated>2011-09-22T03:31:00Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Comparison between Mixins and Interfaces */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Mixins vs. Interfaces=&lt;br /&gt;
&lt;br /&gt;
=Introduction=&lt;br /&gt;
With the advent of object oriented languages, the designers of the language had to come up with the decision of whether or not to include the concept of multiple inheritance. Languages like C++ and Perl allow multiple inheritance whereas the designers of languages like C# and Java decided not to . &lt;br /&gt;
&lt;br /&gt;
While Java like languages implemented interfaces to allow for [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism],languages like Ruby opted not to implement multiple inheritance but to allow the code from one module be added into another class. &lt;br /&gt;
&lt;br /&gt;
Though both interfaces and Mixins simulate multiple inheritance and avoid the common pathologies associated with it , they have their own set of compromises. The below article tries to provide clarity on how this is achieved in each and also provides other distinctive features of Mixins and interfaces. &lt;br /&gt;
&lt;br /&gt;
===Interfaces===&lt;br /&gt;
In an object-oriented programming languages such as Java, C#, an interface&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/ Interfaces] &amp;lt;/ref&amp;gt; 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. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
&lt;br /&gt;
  public interface ParkingLot {&lt;br /&gt;
        boolean add(Car car, int slot);&lt;br /&gt;
        boolean remove(Car car);&lt;br /&gt;
        boolean findCar(Int number);&lt;br /&gt;
        int freeSlotsCount();&lt;br /&gt;
        int occupiedSlots();&lt;br /&gt;
        int parkingType();&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration);&lt;br /&gt;
        int findParkingSlot();&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
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. Interfaces provide an alternative  for languages like Java that does not allow multiple inheritance .&lt;br /&gt;
&lt;br /&gt;
In Java, a class can inherit from only one class but it can implement more than one interface. Therefore, objects can have multiple types: the type of their own class and the types of all the interfaces that they implement. This means that if a variable is declared to be the type of an interface, its value can reference any object that is instantiated from any class that implements the interface.&lt;br /&gt;
&lt;br /&gt;
==Mixins==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Modules are defined in Ruby using the ''module'' keyword.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;ref&amp;gt;[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Below is an example for modules and Mixins:&lt;br /&gt;
&lt;br /&gt;
The module ParkingSlot consists of the methods park and unpark&lt;br /&gt;
  &amp;lt;span style=&amp;quot;color:#4682B4&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingSlot&lt;br /&gt;
        def park&lt;br /&gt;
           #code to park the car&lt;br /&gt;
        end&lt;br /&gt;
        def unpark&lt;br /&gt;
           #code to unpark the car&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/span&amp;gt;&lt;br /&gt;
The module ParkingMeter consists of the methods calculate and printreceipt&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#F4A460&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingMeter&lt;br /&gt;
        def calculate&lt;br /&gt;
           #code to calculate the parking fee&lt;br /&gt;
        end&lt;br /&gt;
        def printreceipt&lt;br /&gt;
           #code to print the receipt&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
When a class ''includes'' a module via include Module Name, all the methods on that module become instance methods on the class.&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#6B8E23&amp;quot;&amp;gt;&lt;br /&gt;
  class Parking&lt;br /&gt;
       include ParkingSlot&lt;br /&gt;
       include ParkingMeter&lt;br /&gt;
       def printcardetails&lt;br /&gt;
           #code to print the details and type of car&lt;br /&gt;
       end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
  p=Parking.new   &lt;br /&gt;
  p.park            # -&amp;gt; Method park from module ParkingSlot&lt;br /&gt;
  p.unpark          # -&amp;gt; Method unpark from module ParkingSlot&lt;br /&gt;
  p.calculate       # -&amp;gt; Method calculate from module ParkingMeter&lt;br /&gt;
  p.printreceipt    # -&amp;gt; Method printreceipt from module ParkingMeter&lt;br /&gt;
  p.printcardetails # -&amp;gt; Calls printCarDetails from class&lt;br /&gt;
&lt;br /&gt;
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''.&lt;br /&gt;
&lt;br /&gt;
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 [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Subclasses_and_superclasses superclass].&lt;br /&gt;
&lt;br /&gt;
[[Image:ParkingLot.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
==Supported Languages==&lt;br /&gt;
The following table shows support for Mixins and Interfaces by most commonly used languages.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Languages&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| Ruby&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Java&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Python&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Smalltalk&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Perl&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| C#&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=Multiple Inheritance=&lt;br /&gt;
[[Multiple Inheritance]] refers to a feature in some [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented programming] languages in which a class can inherit behaviors from more than one superclass. This contrasts with single inheritance in which a class can inherit behavior from at most one superclass. &lt;br /&gt;
Though Multiple Inheritance provides its own advantages of improved modularity and ease of reuse of code in certain applications, it has its own set of disadvantages which sometimes outweigh the possible advantages.&lt;br /&gt;
&lt;br /&gt;
==Diamond Problem==&lt;br /&gt;
This section describes the well know “Diamond Problem”&amp;lt;ref&amp;gt;[http://www.artima.com/designtechniques/interfaces2.html Diamond Problem] &amp;lt;/ref&amp;gt; associated with multiple Inheritance and the succeeding sections describe how Mixins and interfaces can be used to overcome this problem.&lt;br /&gt;
The diamond problem is the ambiguity that can occur when a class inherits from two different classes that both descend from a common superclass. For example, consider a scenario where one decides to combine the Frog and Dinosaur species which both are inherited from the Animal class. The talk() method in the Animal class is abstract and both Frog and Dinosaur needs to implement this method.&lt;br /&gt;
&lt;br /&gt;
Lets say both Frog and Dinosaur implement the talk method like this:&lt;br /&gt;
&lt;br /&gt;
    public class Frog extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Frog, I can croak “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
and,&lt;br /&gt;
    public class Dinosaur extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Dinosaur, I can roar “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
[[Image:Diamond_problem.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
When the Frogsaur is created, it inherits from both Frog and Dinosaur. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    public class Frogsaur extends Frog, Dinosaur {&lt;br /&gt;
       // Note below syntax is used just for demonstration. However java might throw compile time error.&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
The real problem occurs when someone tries to invoke talk() method on a Frogsaur object from the Animal reference.&lt;br /&gt;
    &lt;br /&gt;
    Animal species = new Frogsaur();&lt;br /&gt;
    species.talk(); // which method to invoke ???&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Due to the ambiguity caused by the diamond problem, it isn’t clear whether the runtime system should invoke Frog’s talk() method or Dinosaur talk() method.&lt;br /&gt;
&lt;br /&gt;
==Approaches==&lt;br /&gt;
Different programming languages have addressed the diamond problem in different ways.&lt;br /&gt;
&lt;br /&gt;
In Java, interfaces solve all these ambiguities caused by the diamond problem. Through interfaces, Java allows multiple inheritance of interface but not of implementation. Implementation, which includes instance variables and method implementations, is always singly inherited. As a result, confusion will never arise in Java over which inherited instance variable or method implementation to use.&lt;br /&gt;
&lt;br /&gt;
Ruby does not support multiple inheritance. Mixin provide a way which eliminates the need for multiple inheritance. Ruby has modules which are just like abstract classes in Java. Modules can have different methods implemented in them. They cannot be instantiated like abstract classes. They cannot inherit from other modules or classes. Ruby classes can inherit from only one superclass but can have unlimited number of modules in them to exploit the usage of predefined implementations in these modules. This provides functionality similar to multiple inheritance avoiding any ambiguities.&lt;br /&gt;
&lt;br /&gt;
The below code in Ruby demonstrates two modules Frog and Dinosaur, each of which contain the talk method defined in them. The Frogsaur class ''includes'' these two methods and defines its own talk method. This example was chosen to exhibit on how Ruby resolves method calls at run time.&lt;br /&gt;
&lt;br /&gt;
  module Frog&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can croak&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  module Dinosaur&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can roar&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  class Frogsaur&lt;br /&gt;
      include Frog &lt;br /&gt;
      include Dinosaur&lt;br /&gt;
         def talk&lt;br /&gt;
             puts &amp;quot;I can roar like a dinosaur and croak like a frog&amp;quot;&lt;br /&gt;
         end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  fs = Frogsaur.new&lt;br /&gt;
  fs.talk         # -&amp;gt; I can roar like a dinosaur and croak like a frog&lt;br /&gt;
&lt;br /&gt;
When the method talk is called on the Frogsaur object, Ruby makes sure that the latest method defined in the hierarchy is chosen. Here in this example, the talk method in the Frogsaur class is defined the latest and hence “I can roar like a dinosaur and croak like a frog” is printed. If there was no method defined in the class, method from the Dinosaur is printed since it is next in the hierarchy specified by the include statements.&lt;br /&gt;
&lt;br /&gt;
=Comparison between Mixins and Interfaces=&lt;br /&gt;
&lt;br /&gt;
This is a general comparision: &lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, modules have the implementation of the methods. So all the classes which include the modules gets the same Implementation because  classes create a reference to these modules.&lt;br /&gt;
|In Java, all classes which implement the interfaces should provide implementation for each of the methods declared in the interface. This might duplicate the code if the two or more classes have similar functionality.&lt;br /&gt;
|-&lt;br /&gt;
| Relatively smaller because the classes automatically get access to methods defined in the modules. Modules server as a central repository&lt;br /&gt;
| Relatively larger because a class implementing more than one interfaces has to provide implementation.&lt;br /&gt;
|-&lt;br /&gt;
| Having more modules in the classes can make code less readable. Ideally mixins are suitable for small teams having few modules. &lt;br /&gt;
| The code is more readable here as the implementation is provided to each method and can be found in place&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, a method inside a module can have Module name as qualifier. Hence it’s possible for a class to have inherit two or more modules which have same names.&lt;br /&gt;
| In Java, the class itself has to provide the implementation of the methods. Inheriting methods of same names from different interfaces will signal an error message.&lt;br /&gt;
|-&lt;br /&gt;
| Modules cannot be inherited and cannot form is-a hierarchy&lt;br /&gt;
| Interfaces can extend another interface and hence can form is-a hierarchy&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Drawbacks of Mixins and Interfaces==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces are also limited to public methods and constants with no implementation.&lt;br /&gt;
&lt;br /&gt;
=Conclusion=&lt;br /&gt;
Although mixins have certain advantages over interfaces, they possess their own share of disadvantages. Mixins are generally used in small frameworks and interfaces , more than solving the problem of multiple inheritance provide polymorphism feature which makes object-oriented code more flexible and easy to modify and maintain.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=See Also=&lt;br /&gt;
1. http://ruby.about.com/od/beginningruby/a/mixin.html&amp;lt;br&amp;gt;&lt;br /&gt;
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ &amp;lt;br&amp;gt;&lt;br /&gt;
3. https://www.re-motion.org/blogs/team/2008/02/20/introducing-mixins-finally/ &amp;lt;br&amp;gt;&lt;br /&gt;
4. https://www.cs.washington.edu/education/courses/cse413/11sp/lectures/ruby_interfaces-etc.pdf &amp;lt;br&amp;gt;&lt;br /&gt;
5. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&amp;amp;printable=yes &amp;lt;br&amp;gt;&lt;br /&gt;
6. http://csis.pace.edu/~bergin/patterns/multipleinheritance.html&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=50192</id>
		<title>CSC/ECE 517 Fall 2011/ch2 2c ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=50192"/>
		<updated>2011-09-22T03:27:56Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Approaches */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Mixins vs. Interfaces=&lt;br /&gt;
&lt;br /&gt;
=Introduction=&lt;br /&gt;
With the advent of object oriented languages, the designers of the language had to come up with the decision of whether or not to include the concept of multiple inheritance. Languages like C++ and Perl allow multiple inheritance whereas the designers of languages like C# and Java decided not to . &lt;br /&gt;
&lt;br /&gt;
While Java like languages implemented interfaces to allow for [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism],languages like Ruby opted not to implement multiple inheritance but to allow the code from one module be added into another class. &lt;br /&gt;
&lt;br /&gt;
Though both interfaces and Mixins simulate multiple inheritance and avoid the common pathologies associated with it , they have their own set of compromises. The below article tries to provide clarity on how this is achieved in each and also provides other distinctive features of Mixins and interfaces. &lt;br /&gt;
&lt;br /&gt;
===Interfaces===&lt;br /&gt;
In an object-oriented programming languages such as Java, C#, an interface&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/ Interfaces] &amp;lt;/ref&amp;gt; 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. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
&lt;br /&gt;
  public interface ParkingLot {&lt;br /&gt;
        boolean add(Car car, int slot);&lt;br /&gt;
        boolean remove(Car car);&lt;br /&gt;
        boolean findCar(Int number);&lt;br /&gt;
        int freeSlotsCount();&lt;br /&gt;
        int occupiedSlots();&lt;br /&gt;
        int parkingType();&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration);&lt;br /&gt;
        int findParkingSlot();&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
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. Interfaces provide an alternative  for languages like Java that does not allow multiple inheritance .&lt;br /&gt;
&lt;br /&gt;
In Java, a class can inherit from only one class but it can implement more than one interface. Therefore, objects can have multiple types: the type of their own class and the types of all the interfaces that they implement. This means that if a variable is declared to be the type of an interface, its value can reference any object that is instantiated from any class that implements the interface.&lt;br /&gt;
&lt;br /&gt;
==Mixins==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Modules are defined in Ruby using the ''module'' keyword.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;ref&amp;gt;[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Below is an example for modules and Mixins:&lt;br /&gt;
&lt;br /&gt;
The module ParkingSlot consists of the methods park and unpark&lt;br /&gt;
  &amp;lt;span style=&amp;quot;color:#4682B4&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingSlot&lt;br /&gt;
        def park&lt;br /&gt;
           #code to park the car&lt;br /&gt;
        end&lt;br /&gt;
        def unpark&lt;br /&gt;
           #code to unpark the car&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/span&amp;gt;&lt;br /&gt;
The module ParkingMeter consists of the methods calculate and printreceipt&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#F4A460&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingMeter&lt;br /&gt;
        def calculate&lt;br /&gt;
           #code to calculate the parking fee&lt;br /&gt;
        end&lt;br /&gt;
        def printreceipt&lt;br /&gt;
           #code to print the receipt&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
When a class ''includes'' a module via include Module Name, all the methods on that module become instance methods on the class.&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#6B8E23&amp;quot;&amp;gt;&lt;br /&gt;
  class Parking&lt;br /&gt;
       include ParkingSlot&lt;br /&gt;
       include ParkingMeter&lt;br /&gt;
       def printcardetails&lt;br /&gt;
           #code to print the details and type of car&lt;br /&gt;
       end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
  p=Parking.new   &lt;br /&gt;
  p.park            # -&amp;gt; Method park from module ParkingSlot&lt;br /&gt;
  p.unpark          # -&amp;gt; Method unpark from module ParkingSlot&lt;br /&gt;
  p.calculate       # -&amp;gt; Method calculate from module ParkingMeter&lt;br /&gt;
  p.printreceipt    # -&amp;gt; Method printreceipt from module ParkingMeter&lt;br /&gt;
  p.printcardetails # -&amp;gt; Calls printCarDetails from class&lt;br /&gt;
&lt;br /&gt;
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''.&lt;br /&gt;
&lt;br /&gt;
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 [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Subclasses_and_superclasses superclass].&lt;br /&gt;
&lt;br /&gt;
[[Image:ParkingLot.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
==Supported Languages==&lt;br /&gt;
The following table shows support for Mixins and Interfaces by most commonly used languages.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Languages&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| Ruby&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Java&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Python&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Smalltalk&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Perl&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| C#&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=Multiple Inheritance=&lt;br /&gt;
[[Multiple Inheritance]] refers to a feature in some [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented programming] languages in which a class can inherit behaviors from more than one superclass. This contrasts with single inheritance in which a class can inherit behavior from at most one superclass. &lt;br /&gt;
Though Multiple Inheritance provides its own advantages of improved modularity and ease of reuse of code in certain applications, it has its own set of disadvantages which sometimes outweigh the possible advantages.&lt;br /&gt;
&lt;br /&gt;
==Diamond Problem==&lt;br /&gt;
This section describes the well know “Diamond Problem”&amp;lt;ref&amp;gt;[http://www.artima.com/designtechniques/interfaces2.html Diamond Problem] &amp;lt;/ref&amp;gt; associated with multiple Inheritance and the succeeding sections describe how Mixins and interfaces can be used to overcome this problem.&lt;br /&gt;
The diamond problem is the ambiguity that can occur when a class inherits from two different classes that both descend from a common superclass. For example, consider a scenario where one decides to combine the Frog and Dinosaur species which both are inherited from the Animal class. The talk() method in the Animal class is abstract and both Frog and Dinosaur needs to implement this method.&lt;br /&gt;
&lt;br /&gt;
Lets say both Frog and Dinosaur implement the talk method like this:&lt;br /&gt;
&lt;br /&gt;
    public class Frog extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Frog, I can croak “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
and,&lt;br /&gt;
    public class Dinosaur extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Dinosaur, I can roar “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
[[Image:Diamond_problem.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
When the Frogsaur is created, it inherits from both Frog and Dinosaur. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    public class Frogsaur extends Frog, Dinosaur {&lt;br /&gt;
       // Note below syntax is used just for demonstration. However java might throw compile time error.&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
The real problem occurs when someone tries to invoke talk() method on a Frogsaur object from the Animal reference.&lt;br /&gt;
    &lt;br /&gt;
    Animal species = new Frogsaur();&lt;br /&gt;
    species.talk(); // which method to invoke ???&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Due to the ambiguity caused by the diamond problem, it isn’t clear whether the runtime system should invoke Frog’s talk() method or Dinosaur talk() method.&lt;br /&gt;
&lt;br /&gt;
==Approaches==&lt;br /&gt;
Different programming languages have addressed the diamond problem in different ways.&lt;br /&gt;
&lt;br /&gt;
In Java, interfaces solve all these ambiguities caused by the diamond problem. Through interfaces, Java allows multiple inheritance of interface but not of implementation. Implementation, which includes instance variables and method implementations, is always singly inherited. As a result, confusion will never arise in Java over which inherited instance variable or method implementation to use.&lt;br /&gt;
&lt;br /&gt;
Ruby does not support multiple inheritance. Mixin provide a way which eliminates the need for multiple inheritance. Ruby has modules which are just like abstract classes in Java. Modules can have different methods implemented in them. They cannot be instantiated like abstract classes. They cannot inherit from other modules or classes. Ruby classes can inherit from only one superclass but can have unlimited number of modules in them to exploit the usage of predefined implementations in these modules. This provides functionality similar to multiple inheritance avoiding any ambiguities.&lt;br /&gt;
&lt;br /&gt;
The below code in Ruby demonstrates two modules Frog and Dinosaur, each of which contain the talk method defined in them. The Frogsaur class ''includes'' these two methods and defines its own talk method. This example was chosen to exhibit on how Ruby resolves method calls at run time.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  module Frog&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can croak&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  module Dinosaur&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can roar&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  class Frogsaur&lt;br /&gt;
      include Frog &lt;br /&gt;
      include Dinosaur&lt;br /&gt;
         def talk&lt;br /&gt;
             puts &amp;quot;I can roar like a dinosaur and croak like a frog&amp;quot;&lt;br /&gt;
         end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  fs = Frogsaur.new&lt;br /&gt;
  fs.talk         # -&amp;gt; I can roar like a dinosaur and croak like a frog&lt;br /&gt;
&lt;br /&gt;
When the method talk is called on the Frogsaur object, Ruby makes sure that the latest method defined in the hierarchy is chosen. Here in this example, the talk method in the Frogsaur class is defined the latest and hence “I can roar like a dinosaur and croak like a frog” is printed. If there was no method defined in the class, method from the Dinosaur is printed since it is next in the hierarchy specified by the include statements.&lt;br /&gt;
&lt;br /&gt;
=Comparison between Mixins and Interfaces=&lt;br /&gt;
&lt;br /&gt;
This is a general comparision: &lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, modules have the implementation of the methods. So all the classes which include the modules gets the same Implementation because  classes create a reference to these modules.&lt;br /&gt;
|In Java, all classes which implement the interfaces should provide implementation for each of the methods declared in the interface. This might duplicate the code if the 2 or more classes have similar functionality.&lt;br /&gt;
|-&lt;br /&gt;
| Relatively smaller because the classes automatically get access to methods defined in the modules. Modules server as a central repository&lt;br /&gt;
| Relatively larger because a class implementing more than one interfaces has to provide implementation.&lt;br /&gt;
|-&lt;br /&gt;
| Having more modules in the classes can make code less readable. Ideally mixins are suitable for small teams having few modules. &lt;br /&gt;
| The code is more readable here as the implementation is provided to each method and can be found in place&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, a method inside a module can have Module name as qualifier. Hence it’s possible for a class to have inherit two or more modules which have same names.&lt;br /&gt;
| In Java, the class itself has to provide the implementation of the methods. Inheriting methods of same names from different interfaces will signal an error message.&lt;br /&gt;
|-&lt;br /&gt;
| Modules cannot be inherited and cannot form is-a hierarchy&lt;br /&gt;
| Interfaces can extend another interface and hence can form is-a hierarchy&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Drawbacks of Mixins and Interfaces==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces are also limited to public methods and constants with no implementation.&lt;br /&gt;
&lt;br /&gt;
=Conclusion=&lt;br /&gt;
Although mixins have certain advantages over interfaces, they possess their own share of disadvantages. Mixins are generally used in small frameworks and interfaces , more than solving the problem of multiple inheritance provide polymorphism feature which makes object-oriented code more flexible and easy to modify and maintain.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=See Also=&lt;br /&gt;
1. http://ruby.about.com/od/beginningruby/a/mixin.html&amp;lt;br&amp;gt;&lt;br /&gt;
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ &amp;lt;br&amp;gt;&lt;br /&gt;
3. https://www.re-motion.org/blogs/team/2008/02/20/introducing-mixins-finally/ &amp;lt;br&amp;gt;&lt;br /&gt;
4. https://www.cs.washington.edu/education/courses/cse413/11sp/lectures/ruby_interfaces-etc.pdf &amp;lt;br&amp;gt;&lt;br /&gt;
5. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&amp;amp;printable=yes &amp;lt;br&amp;gt;&lt;br /&gt;
6. http://csis.pace.edu/~bergin/patterns/multipleinheritance.html&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=50191</id>
		<title>CSC/ECE 517 Fall 2011/ch2 2c ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=50191"/>
		<updated>2011-09-22T03:27:27Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Diamond Problem */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Mixins vs. Interfaces=&lt;br /&gt;
&lt;br /&gt;
=Introduction=&lt;br /&gt;
With the advent of object oriented languages, the designers of the language had to come up with the decision of whether or not to include the concept of multiple inheritance. Languages like C++ and Perl allow multiple inheritance whereas the designers of languages like C# and Java decided not to . &lt;br /&gt;
&lt;br /&gt;
While Java like languages implemented interfaces to allow for [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism],languages like Ruby opted not to implement multiple inheritance but to allow the code from one module be added into another class. &lt;br /&gt;
&lt;br /&gt;
Though both interfaces and Mixins simulate multiple inheritance and avoid the common pathologies associated with it , they have their own set of compromises. The below article tries to provide clarity on how this is achieved in each and also provides other distinctive features of Mixins and interfaces. &lt;br /&gt;
&lt;br /&gt;
===Interfaces===&lt;br /&gt;
In an object-oriented programming languages such as Java, C#, an interface&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/ Interfaces] &amp;lt;/ref&amp;gt; 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. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
&lt;br /&gt;
  public interface ParkingLot {&lt;br /&gt;
        boolean add(Car car, int slot);&lt;br /&gt;
        boolean remove(Car car);&lt;br /&gt;
        boolean findCar(Int number);&lt;br /&gt;
        int freeSlotsCount();&lt;br /&gt;
        int occupiedSlots();&lt;br /&gt;
        int parkingType();&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration);&lt;br /&gt;
        int findParkingSlot();&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
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. Interfaces provide an alternative  for languages like Java that does not allow multiple inheritance .&lt;br /&gt;
&lt;br /&gt;
In Java, a class can inherit from only one class but it can implement more than one interface. Therefore, objects can have multiple types: the type of their own class and the types of all the interfaces that they implement. This means that if a variable is declared to be the type of an interface, its value can reference any object that is instantiated from any class that implements the interface.&lt;br /&gt;
&lt;br /&gt;
==Mixins==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Modules are defined in Ruby using the ''module'' keyword.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;ref&amp;gt;[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Below is an example for modules and Mixins:&lt;br /&gt;
&lt;br /&gt;
The module ParkingSlot consists of the methods park and unpark&lt;br /&gt;
  &amp;lt;span style=&amp;quot;color:#4682B4&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingSlot&lt;br /&gt;
        def park&lt;br /&gt;
           #code to park the car&lt;br /&gt;
        end&lt;br /&gt;
        def unpark&lt;br /&gt;
           #code to unpark the car&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/span&amp;gt;&lt;br /&gt;
The module ParkingMeter consists of the methods calculate and printreceipt&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#F4A460&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingMeter&lt;br /&gt;
        def calculate&lt;br /&gt;
           #code to calculate the parking fee&lt;br /&gt;
        end&lt;br /&gt;
        def printreceipt&lt;br /&gt;
           #code to print the receipt&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
When a class ''includes'' a module via include Module Name, all the methods on that module become instance methods on the class.&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#6B8E23&amp;quot;&amp;gt;&lt;br /&gt;
  class Parking&lt;br /&gt;
       include ParkingSlot&lt;br /&gt;
       include ParkingMeter&lt;br /&gt;
       def printcardetails&lt;br /&gt;
           #code to print the details and type of car&lt;br /&gt;
       end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
  p=Parking.new   &lt;br /&gt;
  p.park            # -&amp;gt; Method park from module ParkingSlot&lt;br /&gt;
  p.unpark          # -&amp;gt; Method unpark from module ParkingSlot&lt;br /&gt;
  p.calculate       # -&amp;gt; Method calculate from module ParkingMeter&lt;br /&gt;
  p.printreceipt    # -&amp;gt; Method printreceipt from module ParkingMeter&lt;br /&gt;
  p.printcardetails # -&amp;gt; Calls printCarDetails from class&lt;br /&gt;
&lt;br /&gt;
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''.&lt;br /&gt;
&lt;br /&gt;
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 [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Subclasses_and_superclasses superclass].&lt;br /&gt;
&lt;br /&gt;
[[Image:ParkingLot.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
==Supported Languages==&lt;br /&gt;
The following table shows support for Mixins and Interfaces by most commonly used languages.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Languages&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| Ruby&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Java&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Python&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Smalltalk&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Perl&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| C#&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=Multiple Inheritance=&lt;br /&gt;
[[Multiple Inheritance]] refers to a feature in some [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented programming] languages in which a class can inherit behaviors from more than one superclass. This contrasts with single inheritance in which a class can inherit behavior from at most one superclass. &lt;br /&gt;
Though Multiple Inheritance provides its own advantages of improved modularity and ease of reuse of code in certain applications, it has its own set of disadvantages which sometimes outweigh the possible advantages.&lt;br /&gt;
&lt;br /&gt;
==Diamond Problem==&lt;br /&gt;
This section describes the well know “Diamond Problem”&amp;lt;ref&amp;gt;[http://www.artima.com/designtechniques/interfaces2.html Diamond Problem] &amp;lt;/ref&amp;gt; associated with multiple Inheritance and the succeeding sections describe how Mixins and interfaces can be used to overcome this problem.&lt;br /&gt;
The diamond problem is the ambiguity that can occur when a class inherits from two different classes that both descend from a common superclass. For example, consider a scenario where one decides to combine the Frog and Dinosaur species which both are inherited from the Animal class. The talk() method in the Animal class is abstract and both Frog and Dinosaur needs to implement this method.&lt;br /&gt;
&lt;br /&gt;
Lets say both Frog and Dinosaur implement the talk method like this:&lt;br /&gt;
&lt;br /&gt;
    public class Frog extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Frog, I can croak “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
and,&lt;br /&gt;
    public class Dinosaur extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Dinosaur, I can roar “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
[[Image:Diamond_problem.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
When the Frogsaur is created, it inherits from both Frog and Dinosaur. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    public class Frogsaur extends Frog, Dinosaur {&lt;br /&gt;
       // Note below syntax is used just for demonstration. However java might throw compile time error.&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
The real problem occurs when someone tries to invoke talk() method on a Frogsaur object from the Animal reference.&lt;br /&gt;
    &lt;br /&gt;
    Animal species = new Frogsaur();&lt;br /&gt;
    species.talk(); // which method to invoke ???&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Due to the ambiguity caused by the diamond problem, it isn’t clear whether the runtime system should invoke Frog’s talk() method or Dinosaur talk() method.&lt;br /&gt;
&lt;br /&gt;
==Approaches==&lt;br /&gt;
Different programming languages have addressed the diamond problem in different ways&lt;br /&gt;
&lt;br /&gt;
In Java, interfaces solve all these ambiguities caused by the diamond problem. Through interfaces, Java allows multiple inheritance of interface but not of implementation. Implementation, which includes instance variables and method implementations, is always singly inherited. As a result, confusion will never arise in Java over which inherited instance variable or method implementation to use.&lt;br /&gt;
&lt;br /&gt;
Ruby does not support multiple inheritance. Mixin provide a way which eliminates the need for multiple inheritance. Ruby has modules which are just like abstract classes in Java. Modules can have different methods implemented in them. They cannot be instantiated like abstract classes. They cannot inherit from other modules or classes. Ruby classes can inherit from only one superclass but can have unlimited number of modules in them to exploit the usage of predefined implementations in these modules. This provides functionality similar to multiple inheritance avoiding any ambiguities.&lt;br /&gt;
&lt;br /&gt;
The below code in Ruby demonstrates two modules Frog and Dinosaur, each of which contain the talk method defined in them. The Frogsaur class ''includes'' these two methods and defines its own talk method. This example was chosen to exhibit on how Ruby resolves method calls at run time.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  module Frog&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can croak&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  module Dinosaur&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can roar&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  class Frogsaur&lt;br /&gt;
      include Frog &lt;br /&gt;
      include Dinosaur&lt;br /&gt;
         def talk&lt;br /&gt;
             puts &amp;quot;I can roar like a dinosaur and croak like a frog&amp;quot;&lt;br /&gt;
         end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  fs = Frogsaur.new&lt;br /&gt;
  fs.talk         # -&amp;gt; I can roar like a dinosaur and croak like a frog&lt;br /&gt;
&lt;br /&gt;
When the method talk is called on the Frogsaur object, Ruby makes sure that the latest method defined in the hierarchy is chosen. Here in this example, the talk method in the Frogsaur class is defined the latest and hence “I can roar like a dinosaur and croak like a frog” is printed. If there was no method defined in the class, method from the Dinosaur is printed since it is next in the hierarchy specified by the include statements.&lt;br /&gt;
&lt;br /&gt;
=Comparison between Mixins and Interfaces=&lt;br /&gt;
&lt;br /&gt;
This is a general comparision: &lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, modules have the implementation of the methods. So all the classes which include the modules gets the same Implementation because  classes create a reference to these modules.&lt;br /&gt;
|In Java, all classes which implement the interfaces should provide implementation for each of the methods declared in the interface. This might duplicate the code if the 2 or more classes have similar functionality.&lt;br /&gt;
|-&lt;br /&gt;
| Relatively smaller because the classes automatically get access to methods defined in the modules. Modules server as a central repository&lt;br /&gt;
| Relatively larger because a class implementing more than one interfaces has to provide implementation.&lt;br /&gt;
|-&lt;br /&gt;
| Having more modules in the classes can make code less readable. Ideally mixins are suitable for small teams having few modules. &lt;br /&gt;
| The code is more readable here as the implementation is provided to each method and can be found in place&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, a method inside a module can have Module name as qualifier. Hence it’s possible for a class to have inherit two or more modules which have same names.&lt;br /&gt;
| In Java, the class itself has to provide the implementation of the methods. Inheriting methods of same names from different interfaces will signal an error message.&lt;br /&gt;
|-&lt;br /&gt;
| Modules cannot be inherited and cannot form is-a hierarchy&lt;br /&gt;
| Interfaces can extend another interface and hence can form is-a hierarchy&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Drawbacks of Mixins and Interfaces==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces are also limited to public methods and constants with no implementation.&lt;br /&gt;
&lt;br /&gt;
=Conclusion=&lt;br /&gt;
Although mixins have certain advantages over interfaces, they possess their own share of disadvantages. Mixins are generally used in small frameworks and interfaces , more than solving the problem of multiple inheritance provide polymorphism feature which makes object-oriented code more flexible and easy to modify and maintain.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=See Also=&lt;br /&gt;
1. http://ruby.about.com/od/beginningruby/a/mixin.html&amp;lt;br&amp;gt;&lt;br /&gt;
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ &amp;lt;br&amp;gt;&lt;br /&gt;
3. https://www.re-motion.org/blogs/team/2008/02/20/introducing-mixins-finally/ &amp;lt;br&amp;gt;&lt;br /&gt;
4. https://www.cs.washington.edu/education/courses/cse413/11sp/lectures/ruby_interfaces-etc.pdf &amp;lt;br&amp;gt;&lt;br /&gt;
5. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&amp;amp;printable=yes &amp;lt;br&amp;gt;&lt;br /&gt;
6. http://csis.pace.edu/~bergin/patterns/multipleinheritance.html&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=50189</id>
		<title>CSC/ECE 517 Fall 2011/ch2 2c ds</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch2_2c_ds&amp;diff=50189"/>
		<updated>2011-09-22T03:26:31Z</updated>

		<summary type="html">&lt;p&gt;Ssreepa: /* Diamond Problem */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Mixins vs. Interfaces=&lt;br /&gt;
&lt;br /&gt;
=Introduction=&lt;br /&gt;
With the advent of object oriented languages, the designers of the language had to come up with the decision of whether or not to include the concept of multiple inheritance. Languages like C++ and Perl allow multiple inheritance whereas the designers of languages like C# and Java decided not to . &lt;br /&gt;
&lt;br /&gt;
While Java like languages implemented interfaces to allow for [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism],languages like Ruby opted not to implement multiple inheritance but to allow the code from one module be added into another class. &lt;br /&gt;
&lt;br /&gt;
Though both interfaces and Mixins simulate multiple inheritance and avoid the common pathologies associated with it , they have their own set of compromises. The below article tries to provide clarity on how this is achieved in each and also provides other distinctive features of Mixins and interfaces. &lt;br /&gt;
&lt;br /&gt;
===Interfaces===&lt;br /&gt;
In an object-oriented programming languages such as Java, C#, an interface&amp;lt;ref&amp;gt;[http://download.oracle.com/javase/tutorial/ Interfaces] &amp;lt;/ref&amp;gt; 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. &lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
&lt;br /&gt;
  public interface ParkingLot {&lt;br /&gt;
        boolean add(Car car, int slot);&lt;br /&gt;
        boolean remove(Car car);&lt;br /&gt;
        boolean findCar(Int number);&lt;br /&gt;
        int freeSlotsCount();&lt;br /&gt;
        int occupiedSlots();&lt;br /&gt;
        int parkingType();&lt;br /&gt;
        int calculateParkingFee(int hours, int charge, int duration);&lt;br /&gt;
        int findParkingSlot();&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
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. Interfaces provide an alternative  for languages like Java that does not allow multiple inheritance .&lt;br /&gt;
&lt;br /&gt;
In Java, a class can inherit from only one class but it can implement more than one interface. Therefore, objects can have multiple types: the type of their own class and the types of all the interfaces that they implement. This means that if a variable is declared to be the type of an interface, its value can reference any object that is instantiated from any class that implements the interface.&lt;br /&gt;
&lt;br /&gt;
==Mixins==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Modules are defined in Ruby using the ''module'' keyword.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;ref&amp;gt;[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Below is an example for modules and Mixins:&lt;br /&gt;
&lt;br /&gt;
The module ParkingSlot consists of the methods park and unpark&lt;br /&gt;
  &amp;lt;span style=&amp;quot;color:#4682B4&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingSlot&lt;br /&gt;
        def park&lt;br /&gt;
           #code to park the car&lt;br /&gt;
        end&lt;br /&gt;
        def unpark&lt;br /&gt;
           #code to unpark the car&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/span&amp;gt;&lt;br /&gt;
The module ParkingMeter consists of the methods calculate and printreceipt&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#F4A460&amp;quot;&amp;gt;&lt;br /&gt;
  module ParkingMeter&lt;br /&gt;
        def calculate&lt;br /&gt;
           #code to calculate the parking fee&lt;br /&gt;
        end&lt;br /&gt;
        def printreceipt&lt;br /&gt;
           #code to print the receipt&lt;br /&gt;
        end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
When a class ''includes'' a module via include Module Name, all the methods on that module become instance methods on the class.&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#6B8E23&amp;quot;&amp;gt;&lt;br /&gt;
  class Parking&lt;br /&gt;
       include ParkingSlot&lt;br /&gt;
       include ParkingMeter&lt;br /&gt;
       def printcardetails&lt;br /&gt;
           #code to print the details and type of car&lt;br /&gt;
       end&lt;br /&gt;
  end&lt;br /&gt;
 &amp;lt;/span&amp;gt;&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
  p=Parking.new   &lt;br /&gt;
  p.park            # -&amp;gt; Method park from module ParkingSlot&lt;br /&gt;
  p.unpark          # -&amp;gt; Method unpark from module ParkingSlot&lt;br /&gt;
  p.calculate       # -&amp;gt; Method calculate from module ParkingMeter&lt;br /&gt;
  p.printreceipt    # -&amp;gt; Method printreceipt from module ParkingMeter&lt;br /&gt;
  p.printcardetails # -&amp;gt; Calls printCarDetails from class&lt;br /&gt;
&lt;br /&gt;
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''.&lt;br /&gt;
&lt;br /&gt;
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 [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Subclasses_and_superclasses superclass].&lt;br /&gt;
&lt;br /&gt;
[[Image:ParkingLot.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
==Supported Languages==&lt;br /&gt;
The following table shows support for Mixins and Interfaces by most commonly used languages.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Languages&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| Ruby&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Java&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Python&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Smalltalk&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Perl&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| C#&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=Multiple Inheritance=&lt;br /&gt;
[[Multiple Inheritance]] refers to a feature in some [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented programming] languages in which a class can inherit behaviors from more than one superclass. This contrasts with single inheritance in which a class can inherit behavior from at most one superclass. &lt;br /&gt;
Though Multiple Inheritance provides its own advantages of improved modularity and ease of reuse of code in certain applications, it has its own set of disadvantages which sometimes outweigh the possible advantages.&lt;br /&gt;
&lt;br /&gt;
==Diamond Problem==&lt;br /&gt;
This section describes the well know “Diamond Problem”&amp;lt;ref&amp;gt;[http://www.artima.com/designtechniques/interfaces2.html Diamond Problem] &amp;lt;/ref&amp;gt; associated with multiple Inheritance and the succeeding sections describe how Mixins and interfaces can be used to overcome this problem.&lt;br /&gt;
The diamond problem is the ambiguity that can occur when a class inherits from two different classes that both descend from a common superclass. For example, consider a scenario where one decides to combine the Frog and Dinosaur species which both are inherited from the Animal class. The talk() method in the Animal class is abstract and both Frog and Dinosaur needs to implement this method.&lt;br /&gt;
&lt;br /&gt;
Lets say both Frog and Dinosaur implement the talk method like this:&lt;br /&gt;
&lt;br /&gt;
    public class Frog extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Frog, I can croak “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
and,&lt;br /&gt;
    public class Dinosaur extends Animal {&lt;br /&gt;
          void talk() {&lt;br /&gt;
               System.out.println(“I am Dinosaur, I can roar “);&lt;br /&gt;
          } &lt;br /&gt;
   }&lt;br /&gt;
&lt;br /&gt;
[[Image:Diamond_problem.PNG | center]]&lt;br /&gt;
&lt;br /&gt;
When the Frogsaur is created, it inherits from both Frog and Dinosaur. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    public class Frogsaur extends Frog, Dinosaur {&lt;br /&gt;
       // Note below syntax is used just for demonstration. However java might throw compile time error.&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
The real problem occurs when someone tries to invoke talk() method on a Frogsaur object from the Animal reference.&lt;br /&gt;
    &lt;br /&gt;
    Animal species = new Frogsaur();&lt;br /&gt;
    animal.talk(); // which method to invoke ???&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Due to the ambiguity caused by the diamond problem, it isn’t clear whether the runtime system should invoke Frog’s talk() method or Dinosaur talk() method.&lt;br /&gt;
&lt;br /&gt;
==Approaches==&lt;br /&gt;
Different programming languages have addressed the diamond problem in different ways&lt;br /&gt;
&lt;br /&gt;
In Java, interfaces solve all these ambiguities caused by the diamond problem. Through interfaces, Java allows multiple inheritance of interface but not of implementation. Implementation, which includes instance variables and method implementations, is always singly inherited. As a result, confusion will never arise in Java over which inherited instance variable or method implementation to use.&lt;br /&gt;
&lt;br /&gt;
Ruby does not support multiple inheritance. Mixin provide a way which eliminates the need for multiple inheritance. Ruby has modules which are just like abstract classes in Java. Modules can have different methods implemented in them. They cannot be instantiated like abstract classes. They cannot inherit from other modules or classes. Ruby classes can inherit from only one superclass but can have unlimited number of modules in them to exploit the usage of predefined implementations in these modules. This provides functionality similar to multiple inheritance avoiding any ambiguities.&lt;br /&gt;
&lt;br /&gt;
The below code in Ruby demonstrates two modules Frog and Dinosaur, each of which contain the talk method defined in them. The Frogsaur class ''includes'' these two methods and defines its own talk method. This example was chosen to exhibit on how Ruby resolves method calls at run time.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  module Frog&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can croak&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  module Dinosaur&lt;br /&gt;
      def talk&lt;br /&gt;
          puts &amp;quot;I can roar&amp;quot;&lt;br /&gt;
      end&lt;br /&gt;
  end&lt;br /&gt;
	&lt;br /&gt;
  class Frogsaur&lt;br /&gt;
      include Frog &lt;br /&gt;
      include Dinosaur&lt;br /&gt;
         def talk&lt;br /&gt;
             puts &amp;quot;I can roar like a dinosaur and croak like a frog&amp;quot;&lt;br /&gt;
         end&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  fs = Frogsaur.new&lt;br /&gt;
  fs.talk         # -&amp;gt; I can roar like a dinosaur and croak like a frog&lt;br /&gt;
&lt;br /&gt;
When the method talk is called on the Frogsaur object, Ruby makes sure that the latest method defined in the hierarchy is chosen. Here in this example, the talk method in the Frogsaur class is defined the latest and hence “I can roar like a dinosaur and croak like a frog” is printed. If there was no method defined in the class, method from the Dinosaur is printed since it is next in the hierarchy specified by the include statements.&lt;br /&gt;
&lt;br /&gt;
=Comparison between Mixins and Interfaces=&lt;br /&gt;
&lt;br /&gt;
This is a general comparision: &lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Mixins&lt;br /&gt;
! Interfaces&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, modules have the implementation of the methods. So all the classes which include the modules gets the same Implementation because  classes create a reference to these modules.&lt;br /&gt;
|In Java, all classes which implement the interfaces should provide implementation for each of the methods declared in the interface. This might duplicate the code if the 2 or more classes have similar functionality.&lt;br /&gt;
|-&lt;br /&gt;
| Relatively smaller because the classes automatically get access to methods defined in the modules. Modules server as a central repository&lt;br /&gt;
| Relatively larger because a class implementing more than one interfaces has to provide implementation.&lt;br /&gt;
|-&lt;br /&gt;
| Having more modules in the classes can make code less readable. Ideally mixins are suitable for small teams having few modules. &lt;br /&gt;
| The code is more readable here as the implementation is provided to each method and can be found in place&lt;br /&gt;
|-&lt;br /&gt;
| In Ruby, a method inside a module can have Module name as qualifier. Hence it’s possible for a class to have inherit two or more modules which have same names.&lt;br /&gt;
| In Java, the class itself has to provide the implementation of the methods. Inheriting methods of same names from different interfaces will signal an error message.&lt;br /&gt;
|-&lt;br /&gt;
| Modules cannot be inherited and cannot form is-a hierarchy&lt;br /&gt;
| Interfaces can extend another interface and hence can form is-a hierarchy&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Drawbacks of Mixins and Interfaces==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces are also limited to public methods and constants with no implementation.&lt;br /&gt;
&lt;br /&gt;
=Conclusion=&lt;br /&gt;
Although mixins have certain advantages over interfaces, they possess their own share of disadvantages. Mixins are generally used in small frameworks and interfaces , more than solving the problem of multiple inheritance provide polymorphism feature which makes object-oriented code more flexible and easy to modify and maintain.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=See Also=&lt;br /&gt;
1. http://ruby.about.com/od/beginningruby/a/mixin.html&amp;lt;br&amp;gt;&lt;br /&gt;
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ &amp;lt;br&amp;gt;&lt;br /&gt;
3. https://www.re-motion.org/blogs/team/2008/02/20/introducing-mixins-finally/ &amp;lt;br&amp;gt;&lt;br /&gt;
4. https://www.cs.washington.edu/education/courses/cse413/11sp/lectures/ruby_interfaces-etc.pdf &amp;lt;br&amp;gt;&lt;br /&gt;
5. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&amp;amp;printable=yes &amp;lt;br&amp;gt;&lt;br /&gt;
6. http://csis.pace.edu/~bergin/patterns/multipleinheritance.html&lt;/div&gt;</summary>
		<author><name>Ssreepa</name></author>
	</entry>
</feed>