Как реорганизовать одноэлементный класс и избежать повторных ошибок еще

Question

Я начал небольшое приложение в WPF и использовал класс Singleton для обработки всей логики приложения. Кроме того, у меня было несколько ObservableCollections, которые привязаны к DataGrids в представлении.

Проблема: то, что должно было стать маленькой программой, начало функционировать, и код теперь слишком прост в обслуживании, повторном использовании и существует высокий уровень связывания кода.

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

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

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

Answer 1

Статические классы считаются злыми некоторыми людьми, но это всего лишь мнение. Когда у меня есть эти вопросы, я взглянул на .NET-framework: как он разрешен внутри?

Иногда синглтон может быть реорганизован на статический класс. Это зависит от ситуации. Если ваш singleton имеет тип, который наследует (читает: должен наследовать) другие классы или интерфейсы, он не может быть преобразован в статический класс, поскольку статический класс не может наследовать ничего.

Если создать статический класс, стараются соблюдать следующие правила: (Эти правила также подчиняются структуре .NET):

• Все статические члены должны быть поточно.

Вот и все! :)

Правило звучит просто, но подразумевает много:

• Все статические члены работают независимо друг от друга. Таким образом, один вызов никогда не повлияет на результат другого вызова.
• Статический класс не может поддерживать состояние (статическое).
• Если класс имеет статические поля, убедитесь, что они являются readonly или const. Убедитесь, что содержимое этих полей никогда не изменяется.

Конечно, могут быть некоторые небольшие исключения. Например: статический класс может поддерживать внутренний словарь для получения результатов кэширования. Изменение этого кеша должно быть потокобезопасным. Поскольку это внутренний материал, для внешнего мира статический класс по-прежнему подчиняется правилам, изложенным выше.

Итак ... вкратце: если ваш singleton НЕ является потокобезопасным (имеет состояние и т. Д.), НЕ преобразуйте его в статический класс.

* EDIT *

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

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