Создание одного класса для всего этого не является хорошей практикой, поэтому рекомендуется структурировать свой проект и хранить элементы, принадлежащие друг другу, отдельно от случайности.
Отличным примером этого былПроект, который я перенял у коллеги.Был 1 класс, названный Методами.Он содержал более 10 тыс. Строк методов.
Затем я отнес их к ок.20 файлов, и структура была восстановлена.
Большинство методов из этого проекта проверяли пользовательский ввод, который можно легко переместить в static class Validation.
Одна ужасная вещь, которую я заметил, этоизменяемые публичные и статические переменные.Это плохо по нескольким причинам:
- Неправильное поведение, потому что, если какой-то метод изменяет это, хотя он не должен этого делать, он заставляет другие методы вести себя ненадлежащим образом, и это действительно трудно отследитьdown / debug.
- Параллелизм, как мы будем обеспечивать безопасность потоков?Мы даем это всем методам, которые работают с этим?Скажите, если это тип значения, что мы позволим им заблокировать?Что если какой-то метод забудет сделать его потокобезопасным?
- Возможность расширения (надеюсь, вы понимаете, что я имею в виду), если у вас есть, например, данные статического класса, в которых хранятся все эти общедоступные статические переменные, чтоты не должен былОн может сохранить это один раз, если, например, вы можете немного изменить структуру приложения и сказать, что хотите сделать возможной загрузку двух проектов на одном экране, это очень трудно сделать возможным, поскольку вы не можете создать дваэкземпляры статического класса.Существует только один класс, и он останется таким.
Для номера 3 более чистым решением будет хранить либо список экземпляров класса данных, либо хранить ссылку наКласс данных по умолчанию и / или активный.
Статический член и закрытые статические члены (или защищенные) являются хорошей практикой, если вы не создаете огромные классы и методы связаны между собой.
Публичные и статические переменные допустимы, если они на самом деле не являются переменными.
Два способа сделать это - пометить их как постоянные (модификатор const) или только для чтения (модификатор readonly).
Пример:
public class UtilitiesClass
{
internal UtilitiesClass() { }
public void UtilityMethod1()
{
// Do something
}
}
// Method 1 (readonly):
public static readonly UtilitiesClass Utilities = new UtilitiesClass();
// Method 2 (property):
private static UtilitiesClass _utilities = new UtilitiesClass();
public static UtilitiesClass Utilities
{
get { return _utilities; }
private set { _utilities = value; }
}
Преимущество метода 1 заключается в том, что вам вообще не нужно беспокоиться о безопасности потоков, значение не может измениться.
Метод 2 не является поточно-ориентированным (хотя это не так сложно сделать), но он имеет преимущество, заключающееся в том, что сам статический класс может изменять ссылку на класс утилит.