Как я могу избежать/осуществить рефакторинг плохих одиночных элементов на практике?
Я рекомендую WebAii, так как это - то, что я имел любой успех с и при использовании его, мои схватывания были немногими. Я никогда не пробовал Селена, и я не помню использовать WaTiN очень, по крайней мере, не к точке, где я мог заставить его успешно работать. Я не знаю ни о какой платформе, которая имеет дело с диалоговыми окнами Windows корректно, хотя WebAii имеет интерфейс для реализации Ваших собственных диалоговых обработчиков.
4 ответа
Использовать структуру внедрения зависимостей и инверсии управления - это может потребовать значительного рефакторинга. Затем, используя конструктор или зависимость свойств, запросите "синглтон" - в идеале вы не запрашиваете все, так как по принципу Деметры он должен запрашивать только то, что ему действительно нужно (в вашем случае лицензия информации).
Я пытаюсь различать синглтон (антипаттерн, маскирующий глобальные переменные) и синглтон (то есть то, что вам нужно только одно). Настоящий синглтон создается один раз в начале программы (или на вашей фабрике) и передается объектам, которым он нужен.
Вы говорите
Создайте глобальную фабрику AppConfigFactory, которая может создавать экземпляры AppConfig (ПЛОХО: переносит проблему только на другой класс)
На мой взгляд, это совсем неплохо. По мнению клиента, он запрашивает у фабричного объекта конфигурацию, которую он должен использовать. Он не знает, что это синглтон! Одним махом однотонность инкапсулируется в Factory. [Прагматически Factory вполне может оказаться самим синглтоном, но все должно быть загружено, не так ли?]
Теперь, если вы завершаете доступ к Factory с помощью техники внедрения зависимостей, это уточнение, фундаментальное в том, что только один объект ищет после создания этих объектов AppConfig только фабрика знает, есть они один или много.
И это подводит меня к другой любимой теории ... не существует такого числа, как 1, когда вы начинаете, он выглядит как синглтон, затем растет сложность, и вы обнаруживаете сценарий, в котором какая-то часть вашего приложения (например) использует одну конфигурацию, а другая часть использует другую (например, при динамическом переходе между версиями). Фабрика может скрыть эту сложность.
Как насчет того, чтобы класс имел только статические члены? Например, вместо этого (код C #):
class AppConfig
{
public static readonly AppConfig Instance;
private AppConfig() { }
static AppConfig()
{
Instance = new AppConfig();
}
public string SomeConfigParam { get; set; }
}
Сделайте это:
static class AppConfig
{
public static string SomeConfigParam { get; set; }
}
Синглтоны имеют смысл только в том случае, если вам нужно передать экземпляр - как параметры в функции или значения в коллекции. System.DBNull в .NET - хороший пример синглтона. Если это просто глобальное хранилище данных, к которому каждый должен иметь доступ, статические классы сделают ваш код короче и проще.
Передайте AppConfig через метод setAppConfig () или конструктор, если объекту требуется конфигурация приложения на протяжении всего его жизненного цикла. Если связь между глобальным AppConfig и объектом является условной (то есть требуется только в определенных методах), то передайте ее как дополнительный аргумент.