Это связано с: Что плохого в синглтонах
Можете ли вы привести несколько примеров, где можно избежать синглтонов, используя другие методы? Мне нужно использовать это на С++, чтобы вы могли привести примеры с помощью специальных методов на С++.
Чтобы быть более ясным: как вы могли бы использовать диспетчер файлов, диспетчер ресурсов, диспетчер журналов и т.д. без синглтонов.
Простой: создайте один экземпляр вашего файлового менеджера (или любого другого) класса, а затем, при необходимости, передайте его в своем приложении. Многое будет зависеть от вашей структуры приложения, но обычно у вас есть какой-то объект контроллера, который создает другие важные объекты в приложении. Это может быть задачей для создания экземпляра файлового менеджера, а затем передать его другим объектам, которые он создает, которым нужен файловый менеджер.
Если вы используете синглтон, потому что ДОЛЖНО быть не более одного экземпляра определенного класса, что обычно хорошо. Если вы используете его, потому что одноэлемент - это глобально доступный объект, который позволяет вам не думать о том, как другие объекты общаются друг с другом и что за каждый объект несет ответственность, что вы начинаете сталкиваться с проблемами.
Файловый менеджер - хороший пример. Поначалу кажется, что должен быть только нулевой или один экземпляр объекта файлового менеджера. Но это необходимо? Вы не можете иметь две файловые системы на одной машине одновременно?
Как бы вы реализовали файловый менеджер, диспетчер ресурсов, диспетчер журналов и т.д. без синглтонов.
Не делая их синглонами и передавая их вместо дерева вызовов и объектов-сетей в качестве параметров и ссылок.
Как правило: если вам нужны только n экземпляры, создайте экземпляры только n.
Или: Если два экземпляра хорошо продуманного класса не сталкиваются, не нарушая контракт класса, не делайте его синглом.
Можете ли вы привести несколько примеров, где можно избежать синглтонов, используя другие методы?
В коде более высокого уровня просто создайте экземпляр напрямую и передайте его. Вы должны делать это на максимально высоком уровне, который по-прежнему имеет смысл.
В коде нижнего уровня примите ссылку на существующий экземпляр в качестве параметра. Не принимайте factory, если вы можете избежать этого без создания ham-string вашего дизайна и определенно не называть конструктор /new для вещей, которые не являются ядром для логики этого класса.
Если вы соблюдаете оба этих правила, вы будете неявно управлять количеством создаваемых вами экземпляров и не будете рисовать себя в углу, заставляя дизайн синглтон (что часто бывает недальновидным для начала).
Как бы вы реализовали файловый менеджер, диспетчер ресурсов, менеджер журналов и т.д. без синглотонов
Я бы не стал. Я бы создал классы, которые могли бы быть настроены, и пусть само приложение вызывает кадры о том, сколько экземпляров было создано, и как они создаются.
В то же время я бы не позволял низкоуровневым частям моего приложения вызывать любые снимки. Просто потому, что я пишу в журнал, это не значит, что я должен знать, где он должен быть сохранен, какой уровень иерархии протоколирования я пишу, какие фильтры должны применяться к нему и т.д.
Я бы позволил частным частям моего кода решить эти вещи. Таким образом, если я передумаю, я могу отказаться от предыдущих решений, сдуть и воссоздать код верхнего уровня, а не касаться любого кода, который записывает в журнал (большинство моих приложений).