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.


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