Вложенные классы и бизнес-логика в хранилище? - PullRequest
4 голосов
/ 19 февраля 2010

Для моего приложения мне нужно хранить некоторые данные в массиве со свойствами (string main, string[] status, i nt curParCount и т. Д.).

Я сейчас храню его в этом классе:

class Repository
{
    public static Rep[] rep = new Rep[6];
    public struct Rep
    {
        public string main;
        public string clean;
        public int curParCount;
        public int totalCount;
        public int parStart;
        public int partialStart;
        public double scrollPos;
        public int selectionStart;
        public int selectionEnd;
        public string[] status;
    }    
    public static string repName()
    {
        string name;
        if (MainWindow.repnum == 0)
        { name = "Main Text"; }
        else { name = "Repository " + MainWindow.repnum; }
        return name;
    }
    public static string getStatus(int repNum, int statNum)
    {
        return rep[repNum].status[statNum];
    }                                                                  
 }

Это правильный путь для меня? Это точно не похоже на это.

Ответы [ 5 ]

6 голосов
/ 19 февраля 2010

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

редактировать

Вот моя версия:

class Repository
{
    public class Rep
    {
        public string Main {get; set;}
        public string Clean {get; set;}
        public int CurParCount {get; set;}
        public int TotalCount {get; set;}
        public int ParStart {get; set;}
        public int PartialStart {get; set;}
        public double ScrollPos {get; set;}
        public int SelectionStart {get; set;}
        public int SelectionEnd {get; set;}
        public string[] Statuses {get; set;}
    }                                       


    public const int StatusCount = 6;
    public static List<Rep> Reps = new List<Rep>();

    public static string Name
    {
        get
        { 
            if (MainWindow.repnum == 0)
              return "Main Text";

            return "Repository " + MainWindow.repnum;
        }
    }

    public static string GetStatus(int repIndex, int statIndex)
    { return Reps[repIndex].Status[statIndex]; }
}
3 голосов
/ 19 февраля 2010

Ну, как бы I сделал бы это ...

Public Class Repository: ObservableCollection<RepositoryItem>
{
}


public class RepositoryItem
    {
        public string main {get; set};
        public string clean {get; set};
        public int curParCount {get; set};
        public int totalCount {get; set};
        public int parStart {get; set};
        public int partialStart {get; set};
        public double scrollPos {get; set};
        public int selectionStart {get; set};
        public int selectionEnd {get; set};
        public string[] status {get; };
    }     

По сути, это класс RepositoryItem (который содержит ваши данныелюбые функции, которые вам могут понадобиться для воздействия на эти данные), а затем класс Repository, который наследует класс ObservableCollection, вводя его в RepositoryItem.

2 голосов
/ 19 февраля 2010

ParStart и PartialStart звучат как одно и то же. Вам следует переименовать одно из этих полей, чтобы сделать имя более наглядным. Кроме того, если Par - это сокращение, не сокращайте. Вы должны вообще избегать сокращений (но аббревиатуры в порядке, если они хорошо известны) То же самое касается "Rep", если это сокращение.

Кроме того, я согласен со всеми замечаниями Стивена.

1 голос
/ 19 февраля 2010
    class RepositoryManager
    {
        private static List<Repository> Repo { get; set; }
        .
        .
        .
    }

    public class Repository          
    {
            public string Main { get; set; }
            public string Clean { get; set; }
            public int CurParCount { get; set; }
            .
            .
    }                                           
0 голосов
/ 19 февраля 2010

Есть несколько вещей, которые я бы изменил, чтобы следовать рекомендациям.

Во-первых, я бы рассмотрел проблему с разделением интересов 1004 *. Структура Rep не обязательно должна быть вложенным классом, на мой взгляд, я бы удалил его, вот так (и еще назову это что-то другое):

class Repository 
{ 
    public static Rep[] rep = new Rep[6]; 
}

public struct RepositoryItem
{
    public string main; 
    public string clean; 
    public int curParCount; 
    public int totalCount; 
    public int parStart; 
    public int partialStart; 
    public double scrollPos; 
    public int selectionStart; 
    public int selectionEnd; 
    public string[] status; 
}

Теперь, если вы посмотрите, у вас есть класс Repository, который делает только массив. Поскольку это так, вы можете эффективно устранить это и создать свой массив в качестве переменной и сохранить ее где угодно.

Это оставляет структуру RepositoryItem. Сначала я бы решил проблемы, которые нарушают рекомендации по проектированию библиотек классов . Самое большое нарушение здесь - это именование полей, они должны быть в паскалях :

public struct RepositoryItem
{
    public string Main; 
    public string Clean; 
    public int CurParCount; 
    public int TotalCount; 
    public int ParStart; 
    public int PartialStart; 
    public double ScrollPos; 
    public int SelectionStart; 
    public int SelectionEnd; 
    public string[] Status; 
}

Вы также должны дать своим именам полей больше значимых имен. Хотя «Поз» может быть очевидным для вас, это может быть не очевидно для других. «ScrollPosition» может быть лучшим именем, чем «ScrollPos».

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

Кроме того, учтите последствия, если свойства / поля доступны только для чтения. Если поле «Состояние» доступно только для чтения, рассмотрите возможность представления его как IEnumerable вместо массива, поскольку это даст вам гораздо большую гибкость при назначении значения, чем принудительное использование непрерывной памяти, которая требует массив (также вы защитите от установки элементов в массиве, поскольку ссылка на массив доступна только для чтения, а не элементы самого массива).

...