CSC/ECE 517 Fall 2010/ch3 3b ka: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 22: Line 22:
As it is clearly shown in the above hierarchy, class C inherits the modules A and B by using the "include" keyword. Now when an object of C is created, A and B will not be instantiated since modules have not particular instantiation. This object will still access to all the methods of modules A and B along with the modules defined in the class C. This is different from multiple inheritance in C++ where when a subclass is instantiated, the parent classes get instantiated as well.
As it is clearly shown in the above hierarchy, class C inherits the modules A and B by using the "include" keyword. Now when an object of C is created, A and B will not be instantiated since modules have not particular instantiation. This object will still access to all the methods of modules A and B along with the modules defined in the class C. This is different from multiple inheritance in C++ where when a subclass is instantiated, the parent classes get instantiated as well.


Q1. "Do mixins solve all of these problems?
=Mixins vs Other multiple inheritance =
 
==Runtime Extensions==
 
Mixins allows the programmer to extend the functionality, add methods and change the behavior of core classes at runtime. This feature is extremely useful since these changes will not effect the way the objects are instantiated in the program. This makes writing plugins, extensions and other changes to the framework very easy. In frameworks written in other languages, such as Java, plugging in new functionality means that you need to change how your objects are instantiated.  This will require code changes and/or potentially configuration changes
 
==Diamond Problem==
 
Earlier we had discussed the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_25_ag#Diamond_Problem_in_Detail Diamond Problem] and its impact on [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_25_ag multiple inheritance. Here is how the scenario changes with the usage of mixins. Consider an example where


One very common problem with multiple inheritance is called the Diamond Problem. This can be illustrated with the following example:
One very common problem with multiple inheritance is called the Diamond Problem. This can be illustrated with the following example:

Revision as of 23:38, 6 October 2010

Multiple inheritance and mixins

Introduction

Multiple inheritance is often deemed as a very powerful tool in the Object Oriented Programming paradigm. Implementation of multiple inheritance in languages like Java (interfaces) and C++ is restricted and can often lead to a number of difficulties like the Diamond Problem, Virtual Inheritance issue and increase in programming complexity.

Mixins provide a way to mimic the functionality of multiple inheritance without inheriting the limitations of traditional multiple inheritance. Mixins can be found in languages like Python, Scala, Ruby etc.

Mixins

Mixins are a collection of methods that can be injected into a class without instantiation. It serves as a means of extending the functionality of the sub class. A class can inherit functionality from one or more mixins.

Here is an illustration of how mixins work in Ruby. Mixins are implemented as modules which contains various methods. In the following example, there are two modules, A and B.


Now consider a class C that inherits functionality from both the modules A and B. Here is an illustration of the structure of class C after the multiple inheritance from the two mixins.

As it is clearly shown in the above hierarchy, class C inherits the modules A and B by using the "include" keyword. Now when an object of C is created, A and B will not be instantiated since modules have not particular instantiation. This object will still access to all the methods of modules A and B along with the modules defined in the class C. This is different from multiple inheritance in C++ where when a subclass is instantiated, the parent classes get instantiated as well.

Mixins vs Other multiple inheritance

Runtime Extensions

Mixins allows the programmer to extend the functionality, add methods and change the behavior of core classes at runtime. This feature is extremely useful since these changes will not effect the way the objects are instantiated in the program. This makes writing plugins, extensions and other changes to the framework very easy. In frameworks written in other languages, such as Java, plugging in new functionality means that you need to change how your objects are instantiated. This will require code changes and/or potentially configuration changes

Diamond Problem

Earlier we had discussed the Diamond Problem and its impact on [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_25_ag multiple inheritance. Here is how the scenario changes with the usage of mixins. Consider an example where

One very common problem with multiple inheritance is called the Diamond Problem. This can be illustrated with the following example:

Say two classes B & C both inherit from A and D inherits from B & C. Suppose in class D an object calls a method defined in class A, where B & C have overridden the method, then there is the problem of which class does it inherit from, B or C? The Diamond Problem is solved using virtual inheritance in languages like C++. This is taken care of in Ruby, as the method with the same name that was most recently included would be considered. Hence there is no need of virtual inheritance.

This is demonstrated by the following example:

module A

 def hello
   puts "hello"
 end

end

module B

 def hello
   puts "hello world"
 end

end

class C

 include B
 include A
 puts C.new.hello

end

Output: hello nil

Now instead if we change the order of include in class C

class C

 include A
 include B
 puts C.new.hello

end

Output: hello world nil


However, it is better to avoid such situations altogether. So even though it may seem viable in the above example, it may not be when multiple modules are included within a class.


Q2. Are mixins a clear advance over interfaces?

Java does not use multiple inheritance. Instead it uses interfaces. Moreover in Java, each class can have only one parent. Also, functions declared within the interface cannot be implemented within that interface. An interface cannot have any member variables. However with a mixin, modules can include the implementation of the methods along with their definitions.


Q3. Do mixins have any disadvantages not shared by multiple inheritance or interfaces

Although mixins help solve the diamond problem, there is a disadvantage to it. If the method having the same as the modules which it includes, it implements the method in the class, without providing the user any warning.

module A

 def hello
   puts "hello"
 end

end

module B

 def hello
   puts "hello world"
 end

end

class C

 include A
 include B
 def hello
   puts "this is the Hello from Class C"
 end
 puts C.new.hello

end

Output: this is the Hello from Class C nil


Conclusion:

Although mixins have certain advantages over multiple inheritance and interfaces, they also have their own share of disadvantages. So, we cannot say that mixins are indeed better.


References: CSC 517 Lecture Notes http://en.wikipedia.org/wiki/Multiple_inheritance http://en.wikipedia.org/wiki/Diamond_problem http://ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html http://download.oracle.com/javase/tutorial/java/concepts/interface.html

Further reading: http://www.cprogramming.com/tutorial/virtual_inheritance.html