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

Согласно правилу 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();
    }
}

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


.net c# interface partial-classes
person Tomek Tarczynski    schedule 10.04.2010    source источник

Ответы (3)


arrow_upward
3
arrow_downward

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

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

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

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

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

person Tomas Petricek    schedule 10.04.2010
comment
Я думаю, что в вашем абзаце 2 вы говорите о явных (не неявных) реализациях - возможно, опечатка? - person Kevin Brock; 10.04.2010
comment
Согласен, я думаю, что хуже разделить класс. Частичные классы действительно существуют как инструмент для IDE (например, VS со страницами ASP.NET и выделенным кодом). - person Kevin Brock; 10.04.2010

arrow_upward
1
arrow_downward

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

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

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

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

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

person Marc Gravell    schedule 10.04.2010

arrow_upward
0
arrow_downward

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

person juharr    schedule 10.04.2010