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. :-D
-
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. :-D
There is no limit to how many interfaces a class can implement. It clearly depends on your requirement. The class gets complex with each additional interface implemented. Allowing multiple interfaces to class gives us some benefit of being robust and scalable. Practically, a typical class implements one or two interfaces. but, again it depends on what you want to achieve.
// ♫ 99 little bugs in the code, // 99 bugs in the code // We fix a bug, compile it again // 101 little bugs in the code ♫
-
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. :-D
This is a good question. I guess the answer is that the 'single responsibility' principle is at a somewhat higher level than interfaces, many of which specify a behaviour and not a 'responsibility' as such. For example, would you consider INotifyPropertyChanged or IEnumerable<T> to be 'responsibilities'? I wouldn't, I'd say they label the class as having particular behaviours but tell you nothing about what the class actually does. Another case where it can make sense is where you have a class (or an aggregate class with references to several others) whose responsibility is as a data store. This could be auto-generated from an entity management framework or just in-memory classes. You could specify several interfaces on it for different ways of looking at the data – typically, at least, some of those classes will be enumerable, but you could also create custom interfaces for domain-specific things that you want to be able to do with data. For example let's say you're writing a graphics library, and you want graphs to draw series, you might have a ISeriesDataProvider, and it would make sense to make any of your data storage classes that wrapped a list of numbers implement that. The responsibility of that class is not to provide numbers for a graph – it's still to store the data – but it is a useful behaviour. So your primary thinking is correct: you should only inherit from one 'responsibility provider', whether that be a class or an interface. (Sometimes you inherit from none and write the responsibility into this class, of course.) But you can implement any number of 'behaviour decoration' interfaces. Defining the difference between 'responsibility provider' and 'behaviour decorator' is quite tricky but a good clue is that behaviour decorators usually have only a small number of methods or properties, and what those methods/properties do (and are called) is generic, not domain-specific. For example IEnumerable has one method, INotifyPropertyChanged one event, and my hypothetical ISeriesDataProvider has one property (the data), and the names of those single entities tell you nothing about the rest of the class. IEnumerator has three, which are quite general; I'd consider it a borderline case based on that, though because we know what it is, it is clearly a responsibility provider (an enumerator is there only to enumerate). IList has several and most of them have list-related names (add, remove, etc), so it is clearly a responsibility provider, and you shouldn't generally implement i
-
This is a good question. I guess the answer is that the 'single responsibility' principle is at a somewhat higher level than interfaces, many of which specify a behaviour and not a 'responsibility' as such. For example, would you consider INotifyPropertyChanged or IEnumerable<T> to be 'responsibilities'? I wouldn't, I'd say they label the class as having particular behaviours but tell you nothing about what the class actually does. Another case where it can make sense is where you have a class (or an aggregate class with references to several others) whose responsibility is as a data store. This could be auto-generated from an entity management framework or just in-memory classes. You could specify several interfaces on it for different ways of looking at the data – typically, at least, some of those classes will be enumerable, but you could also create custom interfaces for domain-specific things that you want to be able to do with data. For example let's say you're writing a graphics library, and you want graphs to draw series, you might have a ISeriesDataProvider, and it would make sense to make any of your data storage classes that wrapped a list of numbers implement that. The responsibility of that class is not to provide numbers for a graph – it's still to store the data – but it is a useful behaviour. So your primary thinking is correct: you should only inherit from one 'responsibility provider', whether that be a class or an interface. (Sometimes you inherit from none and write the responsibility into this class, of course.) But you can implement any number of 'behaviour decoration' interfaces. Defining the difference between 'responsibility provider' and 'behaviour decorator' is quite tricky but a good clue is that behaviour decorators usually have only a small number of methods or properties, and what those methods/properties do (and are called) is generic, not domain-specific. For example IEnumerable has one method, INotifyPropertyChanged one event, and my hypothetical ISeriesDataProvider has one property (the data), and the names of those single entities tell you nothing about the rest of the class. IEnumerator has three, which are quite general; I'd consider it a borderline case based on that, though because we know what it is, it is clearly a responsibility provider (an enumerator is there only to enumerate). IList has several and most of them have list-related names (add, remove, etc), so it is clearly a responsibility provider, and you shouldn't generally implement i
@BobJanova Thank you very much for replying to my question. :thumbsup: The main problem I was facing, as you rightly pointed out, was in distinguishing the meaning between responsibility and behaviour and hence couldn't tell if I can implement interfaces IA to IZ on a class without affecting its responsibilites. Through your terms "responsibility provider" and "behaviour decorator" I now understand interface implementation clearly. Thank you very much for the 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. :-D
goodpeapul wrote:
Shouldn't a class have a single responsibility?
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 while still having a single overall responsibility. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
goodpeapul wrote:
Shouldn't a class have a single responsibility?
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 while still having a single overall responsibility. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Thank you very much Ravi Bhavnani. The information you have provided here was useful to me. :)
-
There is no limit to how many interfaces a class can implement. It clearly depends on your requirement. The class gets complex with each additional interface implemented. Allowing multiple interfaces to class gives us some benefit of being robust and scalable. Practically, a typical class implements one or two interfaces. but, again it depends on what you want to achieve.
// ♫ 99 little bugs in the code, // 99 bugs in the code // We fix a bug, compile it again // 101 little bugs in the code ♫
-
Ravi Sant wrote:
There is no limit to how many interfaces a class can implement.
I seriously doubt that. Everything on a computer has a limit.
-
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. :-D
goodpeapul wrote:
My question is how many interfaces can be implemented on a single class?
In my humble opinion asking "how many" is not quite the right focus on the broad issue of why and how to use Interfaces. Clearly Interfaces can have multiple uses: 1. to enforce an implementation contract on implementers of an Interface. That "contract" forcing you at compile-time to deal with failure to 'meet the terms of the contract.' 2. to encapsulate "shared behavior" used consistently across implementers of the Interface. 3. via casting instances of Interface implementers to the Interface: to expose a limited subset of functionality, or content, of the instance to other Objects. 4. via discriminate use of implicit and explicit Interfaces to obtain the advantages of all of the above while avoiding semantic confusion, or overlap. imho the idea of "single responsibility" is as applicable to a set of behaviors (methods, functions), as it is to classes. Interfaces are one tool to help achieve that. It may be of interest to you to read Erich Gamma's comments on interfaces here in this 2005 interview:[^]: scroll down to the section titled "Program to an interface, not an implementation." From a humble student of Interfaces and their strategic uses. best, Bill
"I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." Bjarne Stroustrop circa 1990