Рефакторинг злоупотребления Singleton

Я ограничиваюсь максимум двумя синглетонами в приложении / процессе. Один из них обычно называется SysConfig и содержит вещи, которые в противном случае могли бы оказаться глобальными переменными или другими поврежденными концепциями. У меня нет названия для второго, так как до сих пор я так и не достиг своего предела. : -)

Статические переменные-члены имеют свое применение, но я смотрю на них, как на проктологов. Спасатель, когда он вам нужен, но вероятность того, что вы не найдете лучшего способа решения проблемы, составляет «миллион к одному» (ссылка Сайнфельда).

Создайте базовый класс инструмента, реализующий многопоточный слушатель. Производные классы, которые будут иметь драйверы для конкретных инструментов и т. Д. Создайте экземпляр производного класса для каждого инструмента, а затем сохраните объект в каком-либо контейнере. Во время очистки просто перебирайте контейнер. Каждый экземпляр инструмента должен быть сконструирован путем передачи ему некоторой регистрационной информации о том, куда отправлять его выходные данные / статус / что угодно. Используйте здесь свое воображение. ОО-материал становится довольно мощным.

Отличный вопрос. Несколько быстрых мыслей от меня ...

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

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

Удачи.

Поскольку вы знаете о внедрении зависимостей, рассматривали ли вы возможность использования контейнера IoC для управления временем жизни? См. мой ответ на вопрос о статических классах.

для начала, вы можете ограничить использование синглтона с помощью шаблона «Реестр», что фактически означает, что у вас есть один синглтон, который позволяет вам получить доступ к множеству других предварительно сконфигурированных объектов.

Это не «исправление», а улучшение, оно делает многие объекты, которые являются одиночными, немного более нормальными и поддающимися проверке. например ... (полностью надуманный пример)

HardwareRegistry.SerialPorts.Serial1.Send("blah");

но настоящая проблема, похоже, в том, что вы изо всех сил пытаетесь создать набор объектов, которые хорошо работают вместе. В OO есть два типа шагов ... настройка объектов и разрешение объектам делать свое дело.

так что, возможно, посмотрите, как можно настроить совместную работу не-одиночных объектов, а затем повесить это на реестр.

Статический: -

Здесь множество исключений из правил, но в целом, избегайте этого, но это полезно для выполнения одиночных вычислений и создания методов, которые выполняют «общие» вычисления вне контекста объекта. (например, Math.Min)

Мониторинг данных: -

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

вам нужно что-то вроде InstrumentListner, который использует InstrumentProtocol (который вы подклассифицируете для каждого протокола), я не знаю, LogData. Здесь может быть полезен шаблон команды.

Конфигурация: -

иметь информацию о вашей конфигурации и использовать что-то вроде шаблона «построитель», чтобы преобразовать вашу конфигурацию в набор объектов, настроенных определенным образом. т.е. не сообщайте вашим классам о настройке, создайте объект, который настраивает объекты определенным образом.

Последовательные порты: -

Я много работаю с ними, у меня есть последовательное соединение, которое генерирует поток символов, который публикуется как событие. Затем у меня есть что-то, что интерпретирует поток протокола в значимые команды. Мои классы протокола работают с общим "IConnection", от которого наследуется SerialConnection ..... У меня также есть TcpConnections, MockConnections и т. Д., Чтобы иметь возможность вводить тестовые данные или передавать последовательные порты с одного компьютера на другой и т. Д. Классы протоколов просто интерпретируют поток, имеют машину состояний и отправляют команды. Протокол предварительно сконфигурирован с подключением. В протоколе регистрируются различные вещи, поэтому, когда в нем есть значимые данные, они будут запускаться и делать свое дело. Все это создается из конфигурации в начале или перестраивается на лету, если что-то меняется.

1. Вы (OP), кажется, озабочены OO дизайн, ну, я скажу так, когда буду думать о статических переменных. Основная концепция - инкапсуляция и повторное использование; кое-что, о повторном использовании можно меньше заботиться, но почти всегда нужна инкапсуляция. Если это статическая переменная, она на самом деле не инкапсулирована, не так ли? Подумайте, кому нужен доступ к нему, почему и как далеко вы можете СКРЫТЬ его от клиентского кода. Хороший дизайн часто может изменить свое внутреннее устройство без особого ущерба для клиентов, это то, о чем вы хотите думать . Я согласен со Скоттом Мейерсом («Эффективный C ++») во многих вещах. ООП выходит далеко за рамки ключевого слова class. Если вы никогда об этом не слышали, поищите свойства: да, они могут быть статическими, и в C # есть очень хороший способ их использования. В отличие от буквально с использованием статической переменной . Как я намекнул в начале этого пункта списка: подумайте о том, как не выстрелить себе в ногу позже , поскольку класс меняется со временем, это то, что многие программисты не делают при разработке классов.

2. Взгляните на ту структуру Rx, о которой кто-то упомянул.Модель потоков, которую следует использовать для такой ситуации, как вы описали, нелегко решить без дополнительных подробностей о варианте использования ИМХО. Убедитесь, что вы знаете, что делаете с потоками. Многие люди не могут разгадать нити, чтобы спасти свою жизнь; это не так уж и сложно, быть безопасным можно при (повторном) использовании кода. Помните, что контроллеры часто должны быть отделены от объектов, которыми они управляют (например, не одного и того же класса); если вы этого не знаете, найдите книгу по MVC и купите группу из четырех человек.

3. Зависит от того, что вам нужно. Для многих приложений достаточно класса, который почти полностью заполнен статическими данными; как синглтон бесплатно. Это можно сделать очень ОО. Иногда вы бы предпочли иметь несколько экземпляров или поиграться с инъекциями, что усложняет задачу.

4. Я предлагаю темы и события. Простота создания кода, управляемого событиями, на самом деле одна из приятных вещей в C # ИМХО.

Хм, убиваем синглтоны ...

По моему опыту, многие из наиболее распространенных использования, которые молодые программисты используют синглтоны, являются не более чем пустой тратой ключевого слова class. А именно то, что они имели в виду как модуль с отслеживанием состояния, превращаемый в класс highlander ; и есть несколько плохих одноэлементных реализаций, которым можно соответствовать. Я не знаю, потому ли это, что они не научились тому, что они делают, или потому что у них была только Java в колледже. Вернувшись в страну C, это называется использованием данных в области видимости файла и предоставлением API. В C # (и Java) вы как бы привязаны к тому, чтобы быть классом, больше, чем со многими языками. ООП! = Ключевое слово класса; выучите lhs хорошо.

Прилично написанный класс может использовать статические данные для эффективной реализации синглтона и заставлять компилятор делать всю работу по сохранению его единым целым или единым целым, которое вы когда-либо собираетесь получить. Не НЕ заменяйте синглтоны на наследование, если вы серьезно не знаете, что, черт возьми, делаете. Плохо выполненное наследование таких вещей приводит к более хрупкому коду, который слишком много знает. Классы должны быть тупыми, данные - умными. Это звучит глупо, если вы не посмотрите внимательно на утверждение . Использование наследования IMHO для таких вещей, как правило, плохо (тм), у языков есть понятие модулей / пакетов по какой-то причине.

Если вы готовы, то ведь вы ведь конвертировали его в синглтоны давным-давно, верно? Сядьте и подумайте: как мне лучше всего структурировать это приложение, чтобы оно работало в ХХХ темпе, а затем подумайте, как это ХХХ способом влияет на вещи, например, если сделать это одним способом, будет источник раздора между потоками? За такой час можно многое прочесть. Когда вы станете старше, вы научитесь лучшим техникам.

Вот одно предложение для ХХХ способа начать с: (визуализировать) написать (^ Hing) составной класс контроллера, который работает как менеджер над объектами, на которые он ссылается. Эти объекты были вашими одиночными объектами, а не контроллером, который их хранит, и они всего лишь экземпляры этих классов.Это не лучший дизайн для многих приложений (особенно это может быть проблемой для многопоточных приложений IMHO), но он, как правило, решает то, что заставляет большинство молодых людей достигать синглтона, и он будет работать подходящим образом для огромного количества программы. Это похоже на шаблон проектирования CS 102. Забудьте про синглтон, который вы изучили в CS 607.

Этот управляющий класс, возможно, «Приложение» был бы более подходящим;),в основном решает вашу потребность в синглтонах и хранении конфигурации. Как сделать это возвышенно ООП (при условии, что вы действительно понимаете ООП) и не выстрелить себе в ногу (опять же), это упражнение для вашего собственного образования.

Если это видно, я не поклонник так называемого одноэлементного шаблона, особенно того, как его часто неправильно используют. Удаление кодовой базы от нее часто зависит от того, какой объем рефакторинга вы готовы использовать. Синглтоны похожи на глобальные переменные: удобно, но не по маслу. Хм, думаю, я помещу это в свой файл цитат, там есть хорошая фраза ...

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

Недавно мне пришлось решать похожую проблему, и то, что я сделал, показалось мне хорошо работающим, возможно, это поможет вам:

(1) Сгруппируйте всю "глобальную" информацию в один класс. Назовем его Конфигурация.

(2) Для всех классов, которые использовали эти статические объекты, измените их так, чтобы они (в конечном счете) наследовались от нового абстрактного базового класса, который выглядит примерно так

abstract class MyBaseClass {
    protected Configuration config; // You can also wrap it in a property
    public MyBaseClass(Configuration config) {
        this.config = config;
    }
}

(3) Соответственно измените все конструкторы классов, производных от MyBaseClass. Затем просто создайте один экземпляр Configuration в начале и передавайте его везде.

Минусы:

• Вам придется рефакторить многие конструкторы и все места, в которых они вызываются
• Это не будет хорошо работать, если вы не выводите свои классы верхнего уровня из Object. Ну, вы можете добавить поле config в производный класс, это просто менее элегантно.

Плюсы

• Не так много усилий, чтобы просто изменить наследование и конструкторы, и бац - можно поменять все Configuration.Instance на config.
• Вы полностью избавляетесь от статических переменных; так что теперь не будет проблем, если, например, ваше приложение вдруг превратится в библиотеку, и кто-то попытается вызвать несколько методов одновременно или что-то еще.