Должен ли я разделять свойства и методы в частичных классах?

Question

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

У меня есть класс Product, для которого я создал интерфейс IProduct. Я считаю, что мне нужно сделать Product и абстрактный класс, потому что любой экземпляр его должен быть одним из полдюжины значений для свойства Category. Итак, мой первый вопрос: следующий способ сделать это?

abstract class Product : IProduct 
{ 
    // Fields 
    // Properties 
    // Methods 
} 

interface IProduct 
{ 
    // Properties 
} 

public class Model : IProduct 
{ 
    public Model() 
    { 
     Category = "Model"; 
    } 

    // Model-specific fields 
    // Model-specific properties 
    // Model-specific methods 
} 

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

abstract class Product : IProduct 
{ 
    // Fields 
    // Properties 
    // Methods 
} 

interface IProduct 
{ 
    // Properties 
} 

public partial class Model : IProduct 
{ 
    public Model() 
    { 
     Category = "Model"; 
    } 

    // Model-specific fields 
    // Model-specific properties 
} 

public partial class Model : IProduct 
{ 
    // Model-specific methods 
} 

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

И, наконец, если разделение свойств и методов является хорошей вещью, а Product имеет некоторые методы, применимые ко всем конкретным версиям, следует ли перенести их в отдельный абстрактный класс?

abstract class Product : IProduct 
{ 
    // Fields 
    // Properties 
} 
abstract class Product : IProduct 
{ 
    // Methods 
} 

Answer 1

Единственное использование я вижу в соответствии partial классов, когда две отдельных систем обновления двух файлов. Это справедливо, например, при использовании дизайнеров Visual Studio (например, дизайнер Windows Forms), которые обновляют свой собственный файл класса. Другое дело может быть правдой для другого автоматически генерируемого вами класса. Одна из них поддерживается системой, одна из вас.

Я никогда не испытывал желания иметь два отдельных файла класса partial, которые я поддерживаю. Обычно я использую директивы #region для разделения методов и свойств.

Answer 2

Лично я предпочитаю комбинировать семантический подход и подход, основанный на видимости, для сортировки членов внутри класса. На самом деле я не знаю, кто когда-либо «изобрел» правило для сортировки членов на основе типа языковой сущности (т. Е. Полей в группе, свойств в группе и т. Д.). Это почти не имеет смысла в отношении удобочитаемости.

Полезно использовать директивы #region для их разделения. Кроме того, я предпочитаю использовать горизонтальные линии (------…---), чтобы сделать код более читаемым.

Пример:

public class SomeClass : ParentClass, ISomeInterface 
{ 
    #region ------ Large feature 1 ---------------------------- 
    … // any non-private members related to 'Large feature 1' go here 
    #endregion 

    #region ------ Large feature 2 ---------------------------- 
    … // any non-private members related to 'Large feature 2' go here 
    #endregion 

    #region ------ Implementation of ISomeInterface ----------- 
    … // ISomeInterface implementation goes here, comments are *not* repeated 
    #endregion 

    #region ------ ParentClass overrides ---------------------- 
    … // parent class members' overrides go here, comments are *not* repeated 
    #endregion 

    #region ------ Internals ---------------------------------- 
    … // any private members, i.e. the actual implementation 
    #endregion 
} 

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

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

public int SomeProperty 
{ 
    get { … return someProperty; } 
    set { someProperty = value; … } 
} 
private int someProperty;