How interfaces achieve multiple inheritance

Many books have written that interfaces are a substitute for multiple inheritance, but I don't see any similarities between them.

Inheritance is mainly important for code reuse and functionality, and multiple inheritance helped reuse code from more than one class, but I did not find such a function in the interface, except that the class can inherit more than one interface.

An interface is just a declaration of functions / methods, and it does not contain any part of the implementation by itself, so the class that inherits this interface needs to write its own implementation code.

Thus, I do not feel any code reuse in the case of the interface.

Is there any document or link that will clear my doubts, please reply, share.

+6
source share
6 answers

Regarding code reuse, you're right. In this regard, multiple interfaces do not replace multiple inheritance.

However, there is another aspect of inheritance: it establishes an is-a relationship between the base and subclass. Thus, a class inheriting several superclasses can act like any of them. In this regard, the interfaces serve as a valid replacement, for example. a method that accepts an interface will also accept any class that implements this interface, just as a method will accept any class that is derived from an excluded class. But, as you stated, each class should independently implement interface methods.

Example:

 public interface Foo { int doFoo(); } public interface Bar { long doBar(); } public class Baz { String doBaz() { return "This is baz"; } } public class FooBar extends Baz implements Foo, Bar { public long doBar() { return 123; } public int doFoo() { return 456; } } // Accepts interface Bar implementing objects public void doSomething(Bar b) { System.out.println(b.doBar() * 10); } // Accepts interface Foo implementing objects public void doSomethingOther(Foo f) { System.out.println(f.doFoo() / 10); } // Accepts objects of class Baz and subclasses public void doMore(Baz b) { System.out.println(b.doBaz()); } void bla() { FooBar fb = new FooBar(); // FooBar can act as Foo, Bar, and Baz doSomething(fb); doSomethingOther(fb); doMore(fb); } 
+3
source

You're right.

People mean that a type in C # can implement several interfaces. This is not the same as classical inheritance.

This allows you to use one class in many different contexts, and any class that inherits from such a class, of course, can use the base class implementation for reuse.

+2
source

See this example.

  /*interface 1 with two methods*/ interface IA1 { void Foo1(); void Foo2(); } /*Interface two with two methods */ interface IA2 { void Foo1(); void Foo3(); } /*class implemeting two interfaces now. Here class cannot inherit two classes but can inherit two interfcaes.*/ /* Case1 */ class CA : IA1, IA2 { void IA1.Foo1()//Explicitly Implemented { Console.WriteLine("In IA1.Foo1"); } void IA2.Foo1() //Explicitly Implemented { Console.WriteLine("In IA2.Foo1"); } public void Foo2() //Implicitly Implemented { Console.WriteLine("In IA1.Foo2"); } public void Foo3() //Implicitly Implemented { Console.WriteLine("In IA2.Foo3"); } } /* Case2*/ class CA : IA1, IA2 { public void Foo1() //Implicitly Implemented { Console.WriteLine("In Foo1"); } public void Foo2() //Implicitly Implemented { Console.WriteLine("In Foo2"); } public void Foo3() //Implicitly Implemented { Console.WriteLine("In Foo3"); } } 

Using the concept of an interface, a class can inherit one or more interfaces. And it can implement its own functionality for inherited interfaces.

0
source
  Inheritance is mostly important for re-usability of code and functionality and multiple inheritance was helping to re-use code from more than one class, but in Interface I didn't find any such feature except that a class can inherit from more than one interface. 

True, interfaces facilitate code reuse (especially when combined with polymorphism, inheritance can work wonders!). I could name another situation where interfaces can be useful: callbacks.

Since we have delegates in C #, I doubt if there is any C # developer who will use interfaces as an environment for callbacks (possibly a C # developer using C # 1.0). But for Java developers, how are they going to implement callbacks without delegates? Answer: interfaces.

Delegate Callbacks

 public delegate int Transformer (int x); class Util { public static void Transform (int[] values, Transformer t) { for (int i = 0; i < values.Length; i++) values[i] = t (values[i]); } } class Test { static void Main() { int[] values = { 1, 2, 3 }; Util.Transform (values, Square); foreach (int i in values) Console.Write (i + " "); } static int Square (int x) { return x * x; } } 

Interface Callbacks

 public interface ITransformer { int Transform (int x); } public class Util { public static void TransformAll (int[] values, ITransformer t) { for (int i = 0; i < values.Length; i++) values[i] = t.Transform (values[i]); } } class Squarer : ITransformer { public int Transform (int x) { return x * x; } } static void Main() { int[] values = { 1, 2, 3 }; Util.TransformAll (values, new Squarer()); foreach (int i in values) Console.WriteLine (i); } 

For more information on callbacks, see C # Callbacks with Interfaces and Delegates and Implement Java Callback Procedures .

NOTE: The sample code in this post is taken from the C # 4.0 book in a nutshell (which is also a good reference to C #).

Well-known developers have warned us about the risks of inheritance:
Why extension is evil from Allen Holub
OOP Good details: messaging, duck printing, layout, not inheritance by Nick Fitzgerald
The Seven Deadly Sins in Programming - Sin # 2: Overuse of Eric Gunnerson’s Inheritance

0
source

Inheritance combines two several orthogonal concepts:

  1. The resulting class can implicitly use the methods and fields of the parent class to process those parts of its behavior that correspond to the properties of the parent class.
  2. Derived class objects can be used for almost any parent class object.

    Providing the class with implicit use of methods and fields from more than one parent class can lead to some complex problems, for example. if class X provides an abstract method foo (), classes Y and Z inherit X and provide different implementations of foo (), and class Q tries to inherit Y and Z. If an object o of class Q is passed to a method that expects X (legal, since objects of a derived class can be used where the objects of the parent class can be used), what should happen if this method tries to call o.foo ()?

    Such problems, as a rule, do not exist with interfaces. If the IY and IZ interfaces inherit the IX interface, which contains foo (), and the IQ interface inherits both of them, the class implementing IQ should provide an implementation for IQ.foo (), which will also be used for IY.foo (), IZ .foo () and IX.foo (). This allows you to create ambiguous situations, but it leads to compromises.

0
source

Actually, I don't have a good answer, except C #, Java does not have multiple Inheriance, and it SHOULD have. The whole point of interfaces being able to replace the need for multiple inheritance is like a big lie, which, when repeated many times, becomes true.

The argument is that multiple inheritance causes all these problems, but I continue to hear these arguments from C #, Java developers who have never used C ++. I also don’t remember how C ++ programmers said: "G, I love C ++, but if they just get rid of Multiple Inheritance, it will be a great language." People used it when it was practical, and when not.

Your problem is a classic example of how multiple inheritance would be appropriate. Any suggestion on code refactoring really tells you how to deal with the problem that C #, Java do not have multiple inheritance.

Also, all discussions about “oh delegation is better, la di dah,” confuse religion with design. There is no right way. Things are more useful or less useful, and that’s all.

In your case, Multiple Inheritance will be a more useful and more elegant solution.

As for refactoring your code in a less useful form, to satisfy all religious people who have never used multiple inheritance and believe that “multiple inheritance is bad,” I think you will have to downgrade your code because I don't see C #, Java is "improving" this way soon. Too many people repeat the religious mantra to such a degree of stupidity that I do not see it ever added to the language.

... but, as you can see from the above solutions, most people think that such a solution will be WAY TOO COMPLEX AND CONFLICT!

I would rather take the risk on the territory of "x extends a, b" myself, even if this is a very frightening solution that can disrupt the capabilities of most C #, Java programmers.

What is even more surprising with respect to the solutions proposed above is that everyone here who suggested you reorganize your code into “delegation” because multiple inheritance is bad if they encounter the same problem would solve the problem simply : “x extends a, b” and be done with it, and all their religious arguments regarding “delegation versus inheritance” will disappear. All debate is stupid, and this is only promoted by ignorant programmers who only demonstrate how well they can read from a book and how little they can think for themselves.

You are 100% correct that Multiple Inheritance will help, and no, you are doing something wrong in your code if you think that C #, Java should have it.

-1
source

Source: https://habr.com/ru/post/897740/


All Articles