Здравствуйте, StatujaLeha, Вы писали:

SL>Еще варианты?

UPD: перечитал ответ — как-то резковато получилось, хотя не собирался даже. Расставьте розовых пони и прочих смайликов по вкусу, ок?

Если extensions требуют несколько разных интерфейсов — у вас проблема с дизайном иерархии типов (впрочем, это и так понятно, городить сложное API поверх интерфейсов имеет смысл только в очень ограниченном наборе сценариев). Если распишете подробнее — будет конкретика, если нет — см ниже.

1. Как насчёт варианта с простым наследованием?

2. Если нет — требуйте зависимости явно, ч/з

interface IComplexInterface : ISimpleInterfaceFirst, ISimpleInterfaceSecond
// или
public void Do<T>(T arg)
  where T: ISimpleInterfaceFirst, ISimpleInterfaceSecondExtensions

Неудобно? Ну а смысл тогда писать код, которым самому неудобно пользоваться, я уж про пользователей молчу?

3. Если снова нет — рассмотрите любой язык с динамической типизацией, в шарпе всё-таки падать в последний момент, без жалоб в момент компиляции, не принято

P.S. Гадлайны таки читать стоит, имя класса не должно быть с I. По вопросу: FDG, Choosing Between Class and Interface

DO favor defining classes over interfaces.
Class-based APIs can be evolved with much greater ease than interface-based APIs because it is possible to add members to a class without breaking existing code.

" KRZYSZTOF CWALINA Over the course of the three versions of the .NET Framework, I have talked about this guideline with quite a few developers on our team. Many of them, including those who initially disagreed with the guideline, have said that they regret having shipped some API as an interface. I have not heard of even one case in which somebody regretted that they shipped a class.

" JEFFREY RICHTER I agree with Krzysztof in general. However, you do need to think about some other things. There are some special base classes, such as MarshalByRefObject. If your library type provides an abstract base class that isn't itself derived from MarshalByRefObject, then types that derive from your abstract base class cannot live in a different AppDomain.

...

DO use abstract classes instead of interfaces to decouple the contract from implementations.
Abstract classes, if designed correctly, allow for the same degree of decoupling between contract and implementation.

" BRIAN PEPIN Another sign that you've got a well-defined interface is that the interface does exactly one thing. If you have an interface that has a grab bag of functionality, that's a warning sign. You'll end up regretting it because in the next version of your product you'll want to add new functionality to this rich interface, but you can't.

Ну и заключительный:

" KRZYSZTOF CWALINA I often hear people saying that interfaces specify contracts. I believe this is a dangerous myth. Interfaces, by themselves, do not specify much beyond the syntax required to use an object. The interface-as-contract myth causes people to do the wrong thing when trying to separate contracts from implementation, which is a great engineering practice. Interfaces separate syntax from implementation, which is not that useful, and the myth provides a false sense of doing the right engineering. In reality, the contract is semantics, and these can actually be nicely expressed with some implementation.

Здравствуйте, StatujaLeha, Вы писали:

SL>Еще варианты?

UPD: перечитал ответ — как-то резковато получилось, хотя не собирался даже. Расставьте розовых поней и прочих смайликов по вкусу, ок?

Если extensions требуют несколько разных интерфейсов — у вас проблема с дизайном иерархии типов (впрочем, это и так понятно, городить сложное API поверх интерфейсов имеет смысл только в очень ограниченном наборе сценариев). Если распишете подробнее — будет конкретика, если нет — см ниже.

1. Как насчёт варианта с простым наследованием?

2. Если нет — требуйте зависимости явно, ч/з

interface IComplexInterface : ISimpleInterfaceFirst, ISimpleInterfaceSecond
// или
public void Do<T>(T arg)
  where T: ISimpleInterfaceFirst, ISimpleInterfaceSecondExtensions

Неудобно? Ну а смысл тогда писать код, которым самому неудобно пользоваться, я уж про пользователей молчу?

3. Если снова нет — рассмотрите любой язык с динамической типизацией, в шарпе всё-таки падать в последний момент, без жалоб в момент компиляции, не принято

P.S. Гадлайны таки читать стоит, имя класса не должно быть с I. По вопросу: FDG, Choosing Between Class and Interface

DO favor defining classes over interfaces.
Class-based APIs can be evolved with much greater ease than interface-based APIs because it is possible to add members to a class without breaking existing code.

" KRZYSZTOF CWALINA Over the course of the three versions of the .NET Framework, I have talked about this guideline with quite a few developers on our team. Many of them, including those who initially disagreed with the guideline, have said that they regret having shipped some API as an interface. I have not heard of even one case in which somebody regretted that they shipped a class.

" JEFFREY RICHTER I agree with Krzysztof in general. However, you do need to think about some other things. There are some special base classes, such as MarshalByRefObject. If your library type provides an abstract base class that isn't itself derived from MarshalByRefObject, then types that derive from your abstract base class cannot live in a different AppDomain.

...

DO use abstract classes instead of interfaces to decouple the contract from implementations.
Abstract classes, if designed correctly, allow for the same degree of decoupling between contract and implementation.

" BRIAN PEPIN Another sign that you've got a well-defined interface is that the interface does exactly one thing. If you have an interface that has a grab bag of functionality, that's a warning sign. You'll end up regretting it because in the next version of your product you'll want to add new functionality to this rich interface, but you can't.

Ну и заключительный:

" KRZYSZTOF CWALINA I often hear people saying that interfaces specify contracts. I believe this is a dangerous myth. Interfaces, by themselves, do not specify much beyond the syntax required to use an object. The interface-as-contract myth causes people to do the wrong thing when trying to separate contracts from implementation, which is a great engineering practice. Interfaces separate syntax from implementation, which is not that useful, and the myth provides a false sense of doing the right engineering. In reality, the contract is semantics, and these can actually be nicely expressed with some implementation.