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. :)
-
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