Designing: Multiple interfaces implementation on classes
-
Its been discussed everywhere that a class cannot inherit from multiple classes but can implement multiple interfaces. My question is how many interfaces can be implemented on a single class? Shouldn't a class have a single responsibility? In case of multiple interface implementation, doesn't it allow classes to have multiple responsibilities?:~ What exactly is the idea behind classes going for multiple interfaces and implementing them all on a class? What number of interfaces is good or is bad? (Though "number" may not have a meaning here, I mean to ask what goes into deciding that a class should/shouldn't implement an interface):confused: Any help in this area from anybody shall be of great help. :)
-
Similarly, teats are like martinis; one is not enough, and three are too many.
Will Rogers never met me.
-
Its been discussed everywhere that a class cannot inherit from multiple classes but can implement multiple interfaces. My question is how many interfaces can be implemented on a single class? Shouldn't a class have a single responsibility? In case of multiple interface implementation, doesn't it allow classes to have multiple responsibilities?:~ What exactly is the idea behind classes going for multiple interfaces and implementing them all on a class? What number of interfaces is good or is bad? (Though "number" may not have a meaning here, I mean to ask what goes into deciding that a class should/shouldn't implement an interface):confused: Any help in this area from anybody shall be of great help. :)
You have at least two problems.
goodpeapul wrote:
a class cannot inherit from multiple classes
True in Java, not true in C++.
The top of this page says:
Please do not post programming questions here.
goodpeapul wrote:
Its been discussed everywhere
It might have been discussed "everywhere", but here is not the appropriate place! Peter
Software rusts. Simon Stephenson, ca 1994.
-
Similarly, teats are like martinis; one is not enough, and three are too many.
Will Rogers never met me.
Roger Wright wrote:
three are too many.
Three martinis too many? Three martinis is a warm-up!
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
Its been discussed everywhere that a class cannot inherit from multiple classes but can implement multiple interfaces. My question is how many interfaces can be implemented on a single class? Shouldn't a class have a single responsibility? In case of multiple interface implementation, doesn't it allow classes to have multiple responsibilities?:~ What exactly is the idea behind classes going for multiple interfaces and implementing them all on a class? What number of interfaces is good or is bad? (Though "number" may not have a meaning here, I mean to ask what goes into deciding that a class should/shouldn't implement an interface):confused: Any help in this area from anybody shall be of great help. :)
When I actually programmed for a living, OOP was brand new, and multiple inheritance was part of the lure of OOP. In practice, however, it proved to be very difficult to implement effectively. The potential for collisions among identically named variables and methods with identical signatures among parent classes was problematic. Interfaces were born to expose certain features of a class to other classes, in order to simulate multiple inheritance in a safe way. A class can be written such that it is able to handle every possible manipulation of the data it can access, but by creating different interfaces for different applications, access to the functions available can be limited to only those which are needed for the specific application using the class. I don't know of any limits on the number of interfaces that a class can implement, but I'm sure that somebody smarter than I will let you know, if there is one.
Will Rogers never met me.
-
You have at least two problems.
goodpeapul wrote:
a class cannot inherit from multiple classes
True in Java, not true in C++.
The top of this page says:
Please do not post programming questions here.
goodpeapul wrote:
Its been discussed everywhere
It might have been discussed "everywhere", but here is not the appropriate place! Peter
Software rusts. Simon Stephenson, ca 1994.
You have a point regarding posting the question here... Have reposted the same in a different forum...Thank ya.
-
Similarly, teats are like martinis; one is not enough, and three are too many.
Will Rogers never met me.
A rather unimaginative friend with a well-endowed ex-wife used to say "Anything more than a mouthful and a handful is wasted." Like I said, no imagination.
Software rusts. Simon Stephenson, ca 1994.
-
Its been discussed everywhere that a class cannot inherit from multiple classes but can implement multiple interfaces. My question is how many interfaces can be implemented on a single class? Shouldn't a class have a single responsibility? In case of multiple interface implementation, doesn't it allow classes to have multiple responsibilities?:~ What exactly is the idea behind classes going for multiple interfaces and implementing them all on a class? What number of interfaces is good or is bad? (Though "number" may not have a meaning here, I mean to ask what goes into deciding that a class should/shouldn't implement an interface):confused: Any help in this area from anybody shall be of great help. :)
An interface is merely a contract that ensures a class implementing that interface publishes the appropriate methods and properties. So if you have an interface ILoungePost and another IProgrammingQuestion, and you develop some class which can be posted to the lounge, and is also a programming question, then you would implement both. * * Of course, this is quite impossible as the two example interfaces are mutually exclusive.
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
An interface is merely a contract that ensures a class implementing that interface publishes the appropriate methods and properties. So if you have an interface ILoungePost and another IProgrammingQuestion, and you develop some class which can be posted to the lounge, and is also a programming question, then you would implement both. * * Of course, this is quite impossible as the two example interfaces are mutually exclusive.
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
A rather unimaginative friend with a well-endowed ex-wife used to say "Anything more than a mouthful and a handful is wasted." Like I said, no imagination.
Software rusts. Simon Stephenson, ca 1994.
-
An interface is merely a contract that ensures a class implementing that interface publishes the appropriate methods and properties. So if you have an interface ILoungePost and another IProgrammingQuestion, and you develop some class which can be posted to the lounge, and is also a programming question, then you would implement both. * * Of course, this is quite impossible as the two example interfaces are mutually exclusive.
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
I was at a party once where a drunk guest said in reference to his wife that more than a mouthful was a waste. She was in ear shot and said quite loudly 'well I don't have that problem' while looking at his crotch.
Ouch! Peter
Software rusts. Simon Stephenson, ca 1994.
-
When I actually programmed for a living, OOP was brand new, and multiple inheritance was part of the lure of OOP. In practice, however, it proved to be very difficult to implement effectively. The potential for collisions among identically named variables and methods with identical signatures among parent classes was problematic. Interfaces were born to expose certain features of a class to other classes, in order to simulate multiple inheritance in a safe way. A class can be written such that it is able to handle every possible manipulation of the data it can access, but by creating different interfaces for different applications, access to the functions available can be limited to only those which are needed for the specific application using the class. I don't know of any limits on the number of interfaces that a class can implement, but I'm sure that somebody smarter than I will let you know, if there is one.
Will Rogers never met me.
Funny, I've not come across many languages that support it. C++, obviously, still does, and Eiffel does. Self supports it in the prototypical model, but apart from that I've not come across much. This is a shame - actually MI is a powerful technique that can save a lot of repetition. For example, a mixin Comparable can implement most of the comparison operators based on one expected comparison method - an interface does not have this flexibility. I think a lot of this derives from the difficulty of implementing MI for virutal functions in C++ - the virtual base class problem and repeated inheritance. In a dynamic language, for example, these problems simply do not occur. Self's approach is liberating and worth exploring if you have a suitable machine to play on (it doesn't play with Windows unfortunately). In fact I think a lot of these problems are rooted in the confusion of types with classes. In Smalltalk, two classes can be polymorphism-compatible if unrelated through inheritance. C++ unfortunately opted to limit polymorphism to subclasses, and this example has been copied by almost every language since - in turn leading to throwing out MI as "difficult to implement". Personally, I think its only difficult if vtables form the basis of polymorphism. They are not the only technique available - Self illustrates a lot of the necessary techniques, even in an untyped language it implements type-inference internally to a degree and much of the work of polymorphism occurs at the call site - often resulting in inlining the most common paths, which is actually more efficient than C++'s approach for those cases. The vtable/indirection approach has drawbacks in pipelined architectures - every polymorphic message call results in jump, causing the pipeline to be refreshed at best, at worst resulting in cache misses. In a static class-based language, Eiffel solved most of these problems while C++ was still young. As is frequently the case though, the better implementation does not necessarily become the most popular.
-
Its been discussed everywhere that a class cannot inherit from multiple classes but can implement multiple interfaces. My question is how many interfaces can be implemented on a single class? Shouldn't a class have a single responsibility? In case of multiple interface implementation, doesn't it allow classes to have multiple responsibilities?:~ What exactly is the idea behind classes going for multiple interfaces and implementing them all on a class? What number of interfaces is good or is bad? (Though "number" may not have a meaning here, I mean to ask what goes into deciding that a class should/shouldn't implement an interface):confused: Any help in this area from anybody shall be of great help. :)
Generally, an interface represents a lightweight "behavior" (that is independent of other behaviors) while a class represents a heaver weight "provider of services" (with potentially predefined methods operations). So it's perfectly acceptable for a class to implement several interfaces. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
When I actually programmed for a living, OOP was brand new, and multiple inheritance was part of the lure of OOP. In practice, however, it proved to be very difficult to implement effectively. The potential for collisions among identically named variables and methods with identical signatures among parent classes was problematic. Interfaces were born to expose certain features of a class to other classes, in order to simulate multiple inheritance in a safe way. A class can be written such that it is able to handle every possible manipulation of the data it can access, but by creating different interfaces for different applications, access to the functions available can be limited to only those which are needed for the specific application using the class. I don't know of any limits on the number of interfaces that a class can implement, but I'm sure that somebody smarter than I will let you know, if there is one.
Will Rogers never met me.
Roger Wright wrote:
Interfaces ... simulate multiple inheritance
They do nothing of the sort.
-
Its been discussed everywhere that a class cannot inherit from multiple classes but can implement multiple interfaces. My question is how many interfaces can be implemented on a single class? Shouldn't a class have a single responsibility? In case of multiple interface implementation, doesn't it allow classes to have multiple responsibilities?:~ What exactly is the idea behind classes going for multiple interfaces and implementing them all on a class? What number of interfaces is good or is bad? (Though "number" may not have a meaning here, I mean to ask what goes into deciding that a class should/shouldn't implement an interface):confused: Any help in this area from anybody shall be of great help. :)
I think you need to concentrate on the difference between can and should.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
Roger Wright wrote:
Interfaces ... simulate multiple inheritance
They do nothing of the sort.
I was attempting a weak analogy, and failed miserably. Late nights after hours of studying are obviously not my best times for responses, though they do seem these days to be the only times I have available. :-O
Will Rogers never met me.
-
Funny, I've not come across many languages that support it. C++, obviously, still does, and Eiffel does. Self supports it in the prototypical model, but apart from that I've not come across much. This is a shame - actually MI is a powerful technique that can save a lot of repetition. For example, a mixin Comparable can implement most of the comparison operators based on one expected comparison method - an interface does not have this flexibility. I think a lot of this derives from the difficulty of implementing MI for virutal functions in C++ - the virtual base class problem and repeated inheritance. In a dynamic language, for example, these problems simply do not occur. Self's approach is liberating and worth exploring if you have a suitable machine to play on (it doesn't play with Windows unfortunately). In fact I think a lot of these problems are rooted in the confusion of types with classes. In Smalltalk, two classes can be polymorphism-compatible if unrelated through inheritance. C++ unfortunately opted to limit polymorphism to subclasses, and this example has been copied by almost every language since - in turn leading to throwing out MI as "difficult to implement". Personally, I think its only difficult if vtables form the basis of polymorphism. They are not the only technique available - Self illustrates a lot of the necessary techniques, even in an untyped language it implements type-inference internally to a degree and much of the work of polymorphism occurs at the call site - often resulting in inlining the most common paths, which is actually more efficient than C++'s approach for those cases. The vtable/indirection approach has drawbacks in pipelined architectures - every polymorphic message call results in jump, causing the pipeline to be refreshed at best, at worst resulting in cache misses. In a static class-based language, Eiffel solved most of these problems while C++ was still young. As is frequently the case though, the better implementation does not necessarily become the most popular.
I don't believe vtables and virtual functions are what make MI difficult, or at least it's only part of the reason. Rather it's the data, from my experience, that makes MI difficult. Consider two classes, B & C which both inherit from A. Now make class D which inherits both from B & C. Now without declaring A to be a virtual base class, then when B or C calls a method on A which A should it call it on? Or when casting an instance of D to A, what inheritance chain should be followed? Also, in my experience, MI has only a few applications and can be simulated, where needed, by aggregation and interfaces.
Rob Grainger wrote:
The vtable/indirection approach has drawbacks in pipelined architectures - every polymorphic message call results in jump, causing the pipeline to be refreshed at best, at worst resulting in cache misses
How is this different from message passing? Doesn't a jump to the requisite code occur eventually?
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun -
I think you need to concentrate on the difference between can and should.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
or may and can.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun -
I don't believe vtables and virtual functions are what make MI difficult, or at least it's only part of the reason. Rather it's the data, from my experience, that makes MI difficult. Consider two classes, B & C which both inherit from A. Now make class D which inherits both from B & C. Now without declaring A to be a virtual base class, then when B or C calls a method on A which A should it call it on? Or when casting an instance of D to A, what inheritance chain should be followed? Also, in my experience, MI has only a few applications and can be simulated, where needed, by aggregation and interfaces.
Rob Grainger wrote:
The vtable/indirection approach has drawbacks in pipelined architectures - every polymorphic message call results in jump, causing the pipeline to be refreshed at best, at worst resulting in cache misses
How is this different from message passing? Doesn't a jump to the requisite code occur eventually?
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von BraunAhmed, Sorry about the delay replying. The first point can be decided in the derived class - the appropriate place to do so. Eiffel has solved this problem - before C++ even attempted it, you can simply rename one of the inherited A's, and it becomes obvious. Further, in a true message-based architecture, the question is redundant. All calls and data access are polymorphic, so D can simply define a method A to disambiguate - either by delegating to the original (in prototypical multiple inheritance) or explictly (otherwise). This gives true representation independence - you program to the interface of an object, not its implementation. Yes, it can be simulated by aggregation and interfaces, but that fails in the Comparable example I cited. In that example, defining one method in a class allows mixing in a lot of methods to provide a whole interface (<, <=, >=, >). This can save a lot of repetitive coding, fulfilling the basic principle of Don't Repeat Yourself (DRY). Self implements MI and has a radical inlining architecture. Often, a polymorphic message results in the actual code being inlined at the call site - with code injected to fall back to indirection when the type of the receiver is not amongst the most common cases. For many dispatches, this results in code that is nearly as optimal as hand-crafted C, and allows Self to adopt an approach where everything (including integers etc.) is an object in the real sense - the compiler (a JIT-based compiler) does all the work of making things efficient. It does very well - a fully dynamic compiler with execution times comparable to Java or C#, and frequently better. The lead developers of this were hired by Sun to work on the Java Hotspot compiler for this reason. I recommend looking at the Self documentation at least - looking at the class library there gives a good vision of how Multiple Inheritance is useful for solving real world problems, while avoiding the repetitive coding patterns that interfaces and aggregation based approximations lead to.