Лучший способ разработать структуру кода для многих синглтонов

Многие синглтоны - это ведь оксюморон?

Что ты пытаешься сделать? Почему к ним нужен доступ везде?

Поскольку все они синглтоны, можете ли вы сделать один «большой» класс одиночным синглтоном?

@Katianie, например, FailHandler, который имеет дело с фатальными ошибками (важно)

Вы, вероятно, можете изучить шаблон Service Locator. Он в значительной степени делает то, что вы хотите.

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

@VTT мне нужен такой, потому что такая ошибка меняет ход программы и многое другое, кроме того, есть другие классы, такие как тот, который предоставляет пути

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

Это не синглтон. Это просто глобальный указатель. Синглтон нельзя создать дважды, вы можете создать столько объектов AbcManager, сколько захотите.

@FantasticMrFox Singleton должен только предоставлять глобальный доступ к какому-либо объекту. Ограничение количества объектов (как в классическом одноэлементном определении) - прямое нарушение принципа единой ответственности, которое не приносит ничего, кроме неприятностей.

Читаемость @Attersson и SRP

@VTT Я согласен, поэтому вам следует избегать их. Но синглтоны не являются одиночными, если они не единичны. Этот объект не особенный, просто случайно он один из них. Вопрос должен заключаться в том, как избежать структуры кода глобальных указателей на менеджеров. Хотя глобальный доступ - это специализация концепции синглтона, он даже не должен иметь этого.

@FantasticMrFox Ну, я не согласен ... (1) Нет необходимости избегать синглтонов, поскольку это допустимый метод оптимизации. (2) Количество объектов класса, управляемых синглтоном, может быть неограниченным (например, синглтон std::string). Синглтон должен предоставлять только глобальную точку доступа к одному из этих объектов. Или (альтернативный вид) класс, ограничивающий количество одновременно существующих объектов, не следует называть синглтоном (и это количество не обязательно 1).

@VTT the singleton pattern is a software design pattern that restricts the instantiation of a class to one object. Я согласен, что глобальный менеджер может быть полезен, и менеджер может управлять несколькими объектами, может быть даже несколько менеджеров. Но тогда они не одиночки. Это объекты, которые вы используете в глобальной области видимости. Синглтон также не имеет ничего общего с глобальным доступом, хотя почти всегда так он реализуется.

@Phins Хотя удобочитаемость произвольна, я также считаю, что точка зрения на SRP вызывает споры. Вы могли бы выделить несколько синглтонов на основе вызовов (RAII), но это означает, что каждый вызов создает и деконструирует (когда функция завершается) какой-то синглтон. Тогда общее решение для пространства имен кажется очень и очень несовершенным, потому что оно все еще содержит указатели, «доступные отовсюду».

@FantasticMrFox Я предпочитаю оригинальное синглтонное определение «Убедитесь, что у класса есть только один экземпляр, и предоставьте ему глобальную точку доступа». из "Шаблонов проектирования". Как я упоминал ранее, нет смысла создавать общий класс, который ограничивает количество одновременно удаляемых объектов до 1. Такой класс обычно можно легко расширить, чтобы ограничить счет любым числом, поэтому нет смысла использовать специальное имя "Синглтон" для конкретного варианта этого класса, ограничивающий число до 1. Поэтому я предпочитаю называть "одиночными" только классы, реализующие вторую часть, то есть глобальную точку доступа.

@VTT В книге это действительно сказано, но предлагаемая реализация также представляет собой дизайн, который страхует единственный экземпляр. Самая первая строка такая: Ensuring a unique instance. The Singleton pattern makes the sole instance a normal instance of a class, but that class is written so that only one instance can ever be created.

Думаю, можно и так: - static AbcManager* abc;. Вы это имели в виду? Затем вы можете назвать это так: - abc->printTest();. Но никого не поощряют использовать ключевое слово static, если они не собираются изменять значения, присвоенные всему классу, все, что изменено в этой статической переменной, повлияет на все члены, связанные с этим конкретным классом.

@VTT Не будучи единичным, синглтон - это просто глобальный. Приятно иметь глобальную точку доступа в синглтоне. Я думаю, вам следует подумать о новом имени для того, что вы считаете синглтоном, потому что наличие глобальной точки доступа - это просто .. глобальный.

@FantasticMrFox Я думаю, что имя «Синглтон» больше подходит для «поставщика глобальной точки доступа», потому что номер 1 в нем хоть как-то присутствует: 1 глобальная точка доступа к 1 экземпляру. В то время как особый случай «ограниченного количества одновременно существующих экземпляров класса», ограничивающий количество экземпляров до 1, вряд ли заслуживает отдельного названия, потому что такой случай встречается крайне редко.

@VTT, Каждый источник, цитируемый до сих пор в этом разговоре, имеет особенность объекта (как только в 1 экземпляре) как часть определения а также предлагаемой реализации. Это нормально - называть это как угодно в своем собственном пространстве, но с точки зрения формальных определений везде, где я могу найти, говорится, что это будет единый объект. Здесь - еще один, если хотите: To create only one instance of a class in a truly object oriented fashion by adhering to the basic principles of object oriented programming

@FantasticMrFox Моя основная мысль заключается в том, что обычные определения синглтонов вводят в заблуждение и / или имеют тенденцию нарушать принцип SRP. Итак, обычная история состоит в том, что кто-то сначала пишет что-то вроде синглтона Мейерса, а затем заканчивает тем, что пишет жалкие статьи о том, что синглтоны являются злом или синглтоны - плохими для тестирования.