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