Интерфейс и частичные классы

Question

Согласно правилу SA1201 в StyleCop элементы в классе должны отображаться в правильном порядке.
Порядок следующий:

Fields 
Constructors 
Finalizers (Destructors) 
Delegates 
Events 
Enums 
Interfaces 
Properties 
Indexers 
Methods 
Structs 
Classes 

Все нормально, за исключением интерфейсов части, потому что интерфейс может содержать методы, события, свойства и т.д. ...
Если мы хотим быть строгим об этом правиле, то мы выиграли У всех членов интерфейса есть одно место, которое часто очень полезно. По мнению StyleCop, эта проблема может быть решена путем разделения класса на частичные классы.

Пример:

/// <summary> 
/// Represents a customer of the system. 
/// </summary> 
public partial class Customer 
{ 
    // Contains the main functionality of the class. 
} 

/// <content> 
/// Implements the ICollection class. 
/// </content> 
public partial class Customer : ICollection 
{ 
    public int Count 
    { 
     get { return this.count; } 
    } 

    public bool IsSynchronized 
    { 
     get { return false; } 
    } 

    public object SyncRoot 
    { 
     get { return null; } 
    } 

    public void CopyTo(Array array, int index) 
    { 
     throw new NotImplementedException(); 
    } 
} 

Есть ли другие хорошие решения этой проблемы?

Answer 1

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

С другой стороны, если вы используете явные реализации , вы говорите, что хотите реализовать интерфейс, не делая его частью класса. В этом случае имеет смысл держать его отдельно от остальных членов.

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

Если вы считаете, что лучше объединить членов интерфейса вместе, то я предпочел бы просто игнорировать правило StyleCop вместо использования частичных классов (что кажется сумасшедшим обходным путем для меня). Afterall, StyleCop дает вам только совет ...

(*) Если мое предположение неверно, я бы, вероятно, просто проигнорировал правило :-).

Answer 2

Лично я не вижу огромного значения в этом типе правил, но это только я. Но это звучит как это говорит о вложенных типов (он говорит «интерфейсы», а не «реализации интерфейса»), т.е.

class Foo { 
    //... 
    public interface IBar {...} 
    //... 
} 

(так как другое сравнение перечисления)

, в котором случай вы может закажите его, как он предлагает. Я просто не хотел: -p (и вложенные интерфейсы в любом случае редкость).

Если это означает «явные реализации интерфейса», вы можете просто иметь их в этом месте и упорядочить их внутренне, как уже определено.

Answer 3

Помимо частичных классов или выключения этого правила вы также можете написать свое собственное правило, чтобы заменить его.