Охрана ресурсов с Синглтоном?

Question

Я прочитал довольно много постов в блоге и ответов на SO, указывающих на то, что Singleton - плохой дизайн.Ранее я реализовал одноэлементный класс CameraControl.Этот класс управляет камерой, которая подключена к системе.При следующих знаниях:

• Ни при каких обстоятельствах не будет более одной камеры (API камеры, предоставляемый производителем камеры, контролирует все камеры).
• Использование API камерыСоздатель в нескольких местах одновременно вызывал проблемы в прошлом (например, один поток пытался получить изображение, другой поток пытался установить выдержку).
• Мой класс предоставляет только несколько дополнительных методов для отображенияизображение, снятое в пользовательском интерфейсе.Перешлите изображение на детектор лица, ... (то есть оно не потребляет много памяти).

Является ли мой выбор сделать этот класс одиночным классом плохим решением?

Answer 1

Синглтоны считаются запахом, потому что:

• Они являются моральным эквивалентом глобальных переменных, поэтому их использование скрывает зависимости в коде, а не раскрывает их через интерфейсы.

• Они обеспечивают тесную связь, потому что ваш код зависит от конкретного экземпляра определенного типа.Что если вы хотите, чтобы ваш пользовательский интерфейс работал с другим диспетчером камер?

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

Answer 2

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

Где синглтон, вероятно, уместен здесь, если API производитель камеры находится в C, и вы решили предоставить легкая оболочка C ++ для него, используемая (исключительно) ваши классы камеры. Такие легкие обертки являются одним законное использование синглетонов --- в мире нет пути может иметь несколько экземпляров библиотеки в вашем коде. (Обычно, однако, легче иметь адрес класса Camera API и пропустите промежуточную оболочку.)

Answer 3

Является ли мой выбор сделать этот класс одиночным классом плохим решением?

Да.

• Ни при каких обстоятельствах не будет более одной камеры (API камеры, предоставляемый производителем камеры, контролирует все камеры).

Это не делает необходимым доступ к камере через класс Singleton.

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

Использование класса Singleton не принесет вам ничего, что избавит вас от проблемы, которую вы также не можете сделать в не-Singleton классе.

• Мой класс предоставляет только несколько дополнительных методов для отображения изображения, снятого в пользовательском интерфейсе. Переслать изображение на детектор лица ... (т.е. оно не потребляет много памяти).

Тогда нет необходимости создавать богоподобный синглтон-класс.

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

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

Answer 4

Да и Нет

Нет, потому что проблемы с параллелизмом - это проблемы, которые вы не можете "безопасно" избежать, играя с потоками. Рано или поздно плохие механизмы синхронизации вернутся к вам и сломают ваш прекрасный код. Вам понадобятся мьютексы, семафоры и тому подобное для охраны ресурсов.

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

Что касается общих понятий «синглтоны - зло», то потому, что гораздо сложнее понять, как они работают, они являются ООП-версией глобальных переменных. Предположим, что у вас есть синглтон, который модифицируется в 15 местах, как вы все это отслеживаете? Если у вас есть «реальный» объект, вы сможете увидеть, как он передается в параметрах и тому подобное. Синглтон нарушает концепцию объема и легко превращается в беспорядок.

Answer 5

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

Answer 6

Да, сделать его синглтоном - плохой дизайн.Если вам нужен только один объект Camera, просто создайте его.

Если вам нужно убедиться, что объект Camera используется не для повторного входа, то это ответственность не за объект Camera, а замодель потоков.Это отдельная работа.

Answer 7

В этом отношении полезны шаблоны

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