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

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

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

Все в порядке, кроме части Интерфейсы, потому что Интерфейс может содержать методы, события, свойства и т.д...
Если мы хотим быть строгими в отношении этого правила, у нас не будет всех членов Interface в одном месте, что часто очень полезно. Согласно справке 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();
    }
}

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

3 ответа

Решение

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

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

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

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

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

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

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

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

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

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

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

Другие вопросы по тегам