Can't agree on multiple inheritance - I think the risk of potential errors far outweighs the dubious benefits.....
And I still don't like the idea of providing default implementations in interfaces. In my mind an interface should simply define a contract. It's the job of classes which implement the interface to fulfil it. Any code in an interface blurs that distinction.

>Allowing default implementations of each method does not forbid you to overwrite the method later in the class or in extended interfaces - in an extended interface you can also reset to abstract if wanted.
>If two implementations only differ in the implementation of a small # of methods, why not allow for a non-repeat form of code for the rest of the methods ? It is conceptually something like a mixin of behaviour of a base class. The conflict resolution in case of identical method names found in more than 1 interface, explicit implementation of that method, is a small price to pay for the gain of "multiple inheritance for stateless behaviour" and probably safer than relying on the order of declaration found elsewhere.
>
>
>>Surely putting default behaviour in an interface is itself a form of 'tight coupling' - if you wanted different default behaviour you would have to define a new interface. Putting the default in a base class would allow you to implement the same interface but to derive from a base class with different default behaviour if needed....
>>
>>>Would work in some cases well, less so in others, but introduces the tight coupling interfaces are supposed to be guarding against... If you allow a COM based example in a .Net question, things like IPersist* [Stream, File...] are probably handled by helper objects, but the code to connect to the helper object methods has to be duplicated every place where the interface is implemented.
>>
>>Don't see why, with a base class, the connection logic couldn't be there ?
>>
>>>
>>>>You could achieve this by using a common base class for classes implementing the interface ?
>>>
>>>>>One of my beefs with interfaces used to be HAVING to implement each method again in different branches whenever the interface was implemented again. Resulted sometimes in code duplication or unnecessary complicated breaking out into different structures/complex microstructures of services (example: common logging options for Kevins example with and without WCF not needing to be leveraged via another interface/class or operations like zipping common to both transfer mechanisms).
>>>>>
>>>>>One of the nice enhancements in newer Java for me was the option to define a default implementation for interface methods. Has .Net gained this option as well ?
>>>>
>>>
>>>>
>>>> Not only from my DRY enthusiast status, but also because it eliminated some of the britlleness in Java: old, high up interfaces can now be enhanced with new methods without breaking automatically all existing implementations, as those "new&defaulted" methods will not cause compiler errors pointing to missing implemention on all "new" methods.
>>>>>
>>>>>curious
>>>>>
>>>>>thomas
>>>>>
>>>>>>Interfaces aren't used enough by most .NET devs. I'm working with junior devs on my team to help them learn how to use them. There's a really good Pluralsight course by Jeremy Clark that I highly recommend.
>>>>>>
>>>>>>
>>>>>>>Dmitry/(and Viv)
>>>>>>>
>>>>>>>Before Generics came around, there were scenarios where reflection really helped. But the combination of generics and interfaces often reduces the # of instances where it's necessary. Using generics can mean giving a serious second look at a design, and it's usually worth it.