Click here to Skip to main content
15,913,055 members
Home / Discussions / C#
   

C#

 
GeneralRe: how to get hardware unique serial no Pin
GuyThiebaut9-Nov-11 1:45
professionalGuyThiebaut9-Nov-11 1:45 
AnswerRe: how to get hardware unique serial no Pin
Bernhard Hiller9-Nov-11 2:57
Bernhard Hiller9-Nov-11 2:57 
AnswerRe: how to get hardware unique serial no Pin
Alan Balkany11-Nov-11 11:14
Alan Balkany11-Nov-11 11:14 
QuestionDesigning: Multiple interfaces implementation on classes Pin
vinayvraman8-Nov-11 19:27
vinayvraman8-Nov-11 19:27 
AnswerRe: Designing: Multiple interfaces implementation on classes Pin
Ravi Sant8-Nov-11 21:15
Ravi Sant8-Nov-11 21:15 
GeneralRe: Designing: Multiple interfaces implementation on classes Pin
jschell9-Nov-11 11:13
jschell9-Nov-11 11:13 
GeneralRe: Designing: Multiple interfaces implementation on classes Pin
Ravi Sant10-Nov-11 2:29
Ravi Sant10-Nov-11 2:29 
AnswerRe: Designing: Multiple interfaces implementation on classes PinPopular
BobJanova8-Nov-11 23:15
BobJanova8-Nov-11 23:15 
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 it unless your class is primarily a list.

Note that I just made up the terms 'responsibility provider' and 'behaviour decorator' in the process of writing this post and they may have proper names which I'm not aware of.
GeneralRe: Designing: Multiple interfaces implementation on classes Pin
vinayvraman9-Nov-11 0:34
vinayvraman9-Nov-11 0:34 
AnswerRe: Designing: Multiple interfaces implementation on classes Pin
Ravi Bhavnani9-Nov-11 2:07
professionalRavi Bhavnani9-Nov-11 2:07 
GeneralRe: Designing: Multiple interfaces implementation on classes Pin
vinayvraman9-Nov-11 3:58
vinayvraman9-Nov-11 3:58 
AnswerRe: Designing: Multiple interfaces implementation on classes Pin
BillWoodruff10-Nov-11 5:49
professionalBillWoodruff10-Nov-11 5:49 
QuestionHow to Sleep a Thread? Pin
namelkcip8-Nov-11 16:46
namelkcip8-Nov-11 16:46 
AnswerRe: How to Sleep a Thread? Pin
lukeer8-Nov-11 22:00
lukeer8-Nov-11 22:00 
GeneralRe: How to Sleep a Thread? Pin
namelkcip10-Nov-11 4:40
namelkcip10-Nov-11 4:40 
GeneralRe: How to Sleep a Thread? Pin
lukeer10-Nov-11 21:04
lukeer10-Nov-11 21:04 
AnswerRe: How to Sleep a Thread? Pin
BobJanova8-Nov-11 23:19
BobJanova8-Nov-11 23:19 
QuestionWhat am I doing wrong? Pin
Member 83630848-Nov-11 15:33
Member 83630848-Nov-11 15:33 
AnswerRe: What am I doing wrong? Pin
Hum Dum8-Nov-11 17:09
Hum Dum8-Nov-11 17:09 
AnswerRe: What am I doing wrong? Pin
RobCroll8-Nov-11 17:09
RobCroll8-Nov-11 17:09 
QuestionAce OLE driver with Extended Properties Pin
Alaric_8-Nov-11 10:18
professionalAlaric_8-Nov-11 10:18 
AnswerRe: Ace OLE driver with Extended Properties Pin
Dave Kreskowiak8-Nov-11 13:28
mveDave Kreskowiak8-Nov-11 13:28 
GeneralRe: Ace OLE driver with Extended Properties Pin
Alaric_15-Nov-11 9:59
professionalAlaric_15-Nov-11 9:59 
QuestionRemoving Mutex and file lock using DLL injection (Guild Wars) in C# Pin
KairuByte8-Nov-11 8:06
KairuByte8-Nov-11 8:06 
GeneralRe: Removing Mutex and file lock using DLL injection (Guild Wars) in C# Pin
harold aptroot8-Nov-11 8:37
harold aptroot8-Nov-11 8:37 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.