Re[9]: Насколько "вредно" использование singleton?
От: Тот кто сидит в пруду Россия  
Дата: 27.07.10 12:50
Оценка:
Здравствуйте, Sni4ok, Вы писали:

ТКС>>По-хорошему надо бы просто завести по буферу на поток, чтобы не терять много на синхронизации, из которых потом (когда наберется цельная запись лога) асинхронно (overlapped I/O) сбрасывать все в один файл.


S>всё равно эту запись(хоть и асинхронную) вам придётся синхронизировать,


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

S>да и ждать- пока наберётся нужное количество информации, чтобы записать- утопично, поскольку где гарантия что, программа не рухнет прямо через мгновение, а вы потеряете ту информацию ради которой и велось логирование?


Речь идет о конструкциях следующего вида:

MyLog(10) << "doing something with: " << obj.Name() << " and " << obj2.Name();


Конец строки (вернее, разрушение анонимного объекта типа MyLog) — сброс буфера. Потерять половину подобного буфера считаю вполне приемлемым. Если и это не устраивает, целесообразнее будет завести отдельный сервис логгирования, а не мучатся с отдельным файлом для каждой нитки.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[12]: Насколько "вредно" использование singleton?
От: enji  
Дата: 27.07.10 13:10
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, enji, Вы писали:


I>>>Проблема в том, что класс получается зависимым от системы логирования.


E>>А как иначе? Код, который что-то логирует, безусловно зависит от системы логиривания. Класс, который сохраняет сообщения лога куда-либо, так же зависит от системы логирования.


I>Иначе — зависимость только от интерфейса для логирования а не всей системы или синглтона какого.


Ну дык я об этом и говорю... Подразумевается, что система логирования имеет два "интерфейса" — один для регистрации обработчиков, второй — для логирования.

первый — это класс LogStream, второй — интерфейс обработчика, класс LogMessage и функция registerProcessor()

Но внутри то сидят общие данные, к которым полезут как LogStream, так и registerProcessor. Наружу они не видны, клиенты от них не зависят. Дальше есть два варианта — или эти данные глобальны, или LogStream и registerProcessor дополнительно получают некую ссылку. Возможно это наиболее универсальный способ, но тогда надо что бы тот, кто хочет что-нить логировать, имел эту ссылку. ИМХО, таскать во многих объектах такую ссылку нифига не удобно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[13]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.07.10 13:27
Оценка:
Здравствуйте, enji, Вы писали:

E>первый — это класс LogStream, второй — интерфейс обработчика, класс LogMessage и функция registerProcessor()


Это уже слишком много

E>ИМХО, таскать во многих объектах такую ссылку нифига не удобно.


Конечно неудобно, но это не значит, что для решения этой проблемы нужно создавать синглтон.
Re[13]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.07.10 13:30
Оценка: -1
Здравствуйте, blackhearted, Вы писали:

I>>А как можно сделать "создаёт нужную категогрию логирования " без зависимости от системы логирования ?


B>вызывая

B>
B>logSingleton.createCategory("someString");
B>


B>C таким подходом вообще всё логирование — это зависимость от системы логирования.


В данном случае ты проблему зависимости решил с помощью синглтона.

Это именно тот случай, где синглтон не стоит применять.
Re[10]: Насколько "вредно" использование singleton?
От: Sni4ok  
Дата: 27.07.10 13:37
Оценка:
Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>Если и это не устраивает, целесообразнее будет завести отдельный сервис логгирования, а не мучатся с отдельным файлом для каждой нитки.


а вы ещё и отдельный файл для каждой нити делаете? а что вы делаете, когда этих нитей >100 но каждая из них какюу-нибудь фигню для плюёт в лог?
и какже вы потом их мержите, или поведение одной нитки у вас никогда не зависит от поведения(а значит и описания их работы в логе) от других?
Re[14]: Насколько "вредно" использование singleton?
От: enji  
Дата: 27.07.10 14:17
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, enji, Вы писали:


E>>первый — это класс LogStream, второй — интерфейс обработчика, класс LogMessage и функция registerProcessor()


I>Это уже слишком много


Ну тогда готов выслушать ваши предложения по поводу системы логирования

Мой подход таков:
// файл log.h

class LogStream
{
public:
  LogStream(const std::string &what, int severity);
  ~LogStream();
  
  LogStream& operator<<(...);
  ...
};

// файл logRel.h

struct Message
{
  time time;
  std::string what;  
  int severity;
  std::string msg;
};

struct IProcessor
{
  virtual void doLog(const Message &m) = 0;
};

void registerProcessor(const std::string &what, int severity, IProcessor *proc);

// файл log.cpp

struct LogData
{
  void reigster(const std::string &what, int severity, IProcessor *proc);
  void doLog(const Message &m);
  static LogData& get();
};

LogStream::~LogStream()
{
  Message m;
  ...
  LogData::get().doLog(m);
};

void registerProcessor(const std::string &what, int severity, IProcessor *proc)
{
  LogData::get().registerProcessor(what, severity, proc);
}


E>>ИМХО, таскать во многих объектах такую ссылку нифига не удобно.


I>Конечно неудобно, но это не значит, что для решения этой проблемы нужно создавать синглтон.


А что нужно создавать? Неужели вы реально хотите таскать ссылку на систему логирования через всю программу?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[14]: Насколько "вредно" использование singleton?
От: blackhearted Украина  
Дата: 27.07.10 14:22
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, blackhearted, Вы писали:


I>>>А как можно сделать "создаёт нужную категогрию логирования " без зависимости от системы логирования ?


B>>вызывая

B>>
B>>logSingleton.createCategory("someString");
B>>


B>>C таким подходом вообще всё логирование — это зависимость от системы логирования.


I>В данном случае ты проблему зависимости решил с помощью синглтона.


I>Это именно тот случай, где синглтон не стоит применять.


Ваш рецепт логирования на плюсах?
Re[15]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.07.10 14:48
Оценка:
Здравствуйте, blackhearted, Вы писали:

I>>В данном случае ты проблему зависимости решил с помощью синглтона.


I>>Это именно тот случай, где синглтон не стоит применять.


B>Ваш рецепт логирования на плюсах?


Как минимум service locator
Re[15]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.07.10 14:49
Оценка:
Здравствуйте, enji, Вы писали:

I>>Конечно неудобно, но это не значит, что для решения этой проблемы нужно создавать синглтон.


E>А что нужно создавать? Неужели вы реально хотите таскать ссылку на систему логирования через всю программу?


Не конечно. И синглтон тоже не нужен
Re[16]: Насколько "вредно" использование singleton?
От: blackhearted Украина  
Дата: 27.07.10 14:51
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, blackhearted, Вы писали:


I>>>В данном случае ты проблему зависимости решил с помощью синглтона.


I>>>Это именно тот случай, где синглтон не стоит применять.


B>>Ваш рецепт логирования на плюсах?


I>Как минимум service locator


Не тяжеловато-ли будет в нагруженном сервере его использовать для логирования?
Re[17]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.07.10 15:03
Оценка:
Здравствуйте, blackhearted, Вы писали:

B>>>Ваш рецепт логирования на плюсах?


I>>Как минимум service locator


B>Не тяжеловато-ли будет в нагруженном сервере его использовать для логирования?


Что ты понимаешь под словами "service locator" ?

Нужно один раз на объект получить ссылку на логгер. Если это можт повалить нагруженый сервер, то сдаётся проблема где то в другом месте.
Re[18]: Насколько "вредно" использование singleton?
От: blackhearted Украина  
Дата: 27.07.10 15:07
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, blackhearted, Вы писали:


B>>>>Ваш рецепт логирования на плюсах?


I>>>Как минимум service locator


B>>Не тяжеловато-ли будет в нагруженном сервере его использовать для логирования?


I>Что ты понимаешь под словами "service locator" ?


I>Нужно один раз на объект получить ссылку на логгер. Если это можт повалить нагруженый сервер, то сдаётся проблема где то в другом месте.


Я понимаю это так же как и википедия

The service locator pattern is a design pattern used in software development to encapsulate the processes involved in obtaining a service with a strong abstraction layer. This pattern uses a central registry known as the "service locator" which on request returns the information necessary to perform a certain task.


Не вижу преимущества central registry перед singleton.
Re[19]: Насколько "вредно" использование singleton?
От: blackhearted Украина  
Дата: 27.07.10 15:10
Оценка:
I>>Нужно один раз на объект получить ссылку на логгер. Если это можт повалить нагруженый сервер, то сдаётся проблема где то в другом месте.

B>Я понимаю это так же как и википедия


B>

B>The service locator pattern is a design pattern used in software development to encapsulate the processes involved in obtaining a service with a strong abstraction layer. This pattern uses a central registry known as the "service locator" which on request returns the information necessary to perform a certain task.


B>Не вижу преимущества central registry перед singleton.


Т.е. разницы между

Locator locator;
Logger* logger = locator.getLogger(className);


перед

LogSystem ls = LogSystemSingleton.getInstance();
Logger* logger = ls.getLogger(className);
Re[11]: Насколько "вредно" использование singleton?
От: Тот кто сидит в пруду Россия  
Дата: 27.07.10 15:19
Оценка:
Здравствуйте, Sni4ok, Вы писали:

ТКС>>Если и это не устраивает, целесообразнее будет завести отдельный сервис логгирования, а не мучатся с отдельным файлом для каждой нитки.


S>а вы ещё и отдельный файл для каждой нити делаете?


Нет конечно. Но тут кто-то предлагал.

S> а что вы делаете, когда этих нитей >100 но каждая из них какюу-нибудь фигню для плюёт в лог?

S>и какже вы потом их мержите, или поведение одной нитки у вас никогда не зависит от поведения(а значит и описания их работы в логе) от других?

Не ко мне вопрос.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[19]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.07.10 18:48
Оценка:
Здравствуйте, blackhearted, Вы писали:

B>

B>The service locator pattern is a design pattern used in software development to encapsulate the processes involved in obtaining a service with a strong abstraction layer. This pattern uses a central registry known as the "service locator" which on request returns the information necessary to perform a certain task.


B>Не вижу преимущества central registry перед singleton.


ну так service locator не сводится к central registry.

Преимущетсво локатора оного в слабой связности, тестируемости, прозрачности, реюзабельности кода. заплатить за это нужно зависимостью от одного конкретного интерфейса и интерфейсом самого локатора.

В случае с синглтоном всё это отсутствует.

сам central registry и будет синглтоном, но кроме него не будет никаких других синглтонов, ни для лога, ни для чего еще.

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

Есть еще более сильная вещь, dependency injection, но на с++ я видел такое только для COM-объектов.
Re[20]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.07.10 18:55
Оценка:
Здравствуйте, blackhearted, Вы писали:

B>>Не вижу преимущества central registry перед singleton.


B>Т.е. разницы между


B>
B>Locator locator;
B>Logger* logger = locator.getLogger(className);
B>


B>перед


B>
B>LogSystem ls = LogSystemSingleton.getInstance();
B>Logger* logger = ls.getLogger(className);
B>


Локатор дает доступ к самым различным сервисам, а не только к логгеру.

Логгер — это т.н. сквозной функционал, ты что, будешь для каждого такого сервиса синглтон городить ?

Используя dependency injection у тебя получится примерно так

classA::classA(ILogger* pLogger)
{
  this->pLogger = pLogger;
}


или так

classA::SetLogger(ILogger* pLogger)
{
  this->pLogger = pLogger;
}


И это будет работать _само_
Re[21]: Насколько "вредно" использование singleton?
От: Тот кто сидит в пруду Россия  
Дата: 27.07.10 19:20
Оценка: +3
Здравствуйте, Ikemefula, Вы писали:

I>Локатор дает доступ к самым различным сервисам, а не только к логгеру.


I>Логгер — это т.н. сквозной функционал, ты что, будешь для каждого такого сервиса синглтон городить ?


I>Используя dependency injection у тебя получится примерно так


I>
I>classA::classA(ILogger* pLogger)
I>{
  this->>pLogger = pLogger;
I>}
I>


I>или так


I>
I>classA::SetLogger(ILogger* pLogger)
I>{
  this->>pLogger = pLogger;
I>}
I>


I>И это будет работать _само_


Глупости неудобные. Не надо вносить общность там, где она не требуется. Для логгирования удобен интерфейс в стиле

MyLog(level) << "some message";


для других сервисов — какой-то другой. А уж внутри MyLog хоть сервислокатор зови, хоть к синглтону обращайся — особой разницы нет.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[20]: Насколько "вредно" использование singleton?
От: enji  
Дата: 28.07.10 05:48
Оценка:
Здравствуйте, Ikemefula, Вы писали:

B>>Не вижу преимущества central registry перед singleton.


I>ну так service locator не сводится к central registry.


I>Преимущетсво локатора оного в слабой связности, тестируемости, прозрачности, реюзабельности кода. заплатить за это нужно зависимостью от одного конкретного интерфейса и интерфейсом самого локатора.


I>В случае с синглтоном всё это отсутствует.


I>сам central registry и будет синглтоном, но кроме него не будет никаких других синглтонов, ни для лога, ни для чего еще.


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

Или же этот реестр будет хранить что-то вроде void*, а затем будет иметься кошмарный интерфейс вида reestr::get<LogSystem>()->log("bla bla")

И чем такой подход лучше?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[6]: Насколько "вредно" использование singleton?
От: sidorov18 США  
Дата: 28.07.10 07:46
Оценка:
Здравствуйте, szag, Вы писали:

S>Здравствуйте, sidorov18, Вы писали:


S>>У меня, например, синглтоном класс лог.

S>>А еще есть класс-синглтон, который контент из нета качает и парсит в свои структуры.

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


Это зависит от того, как сделан синглтон, насколько его "синглтоновость" вшита в класс. И может решатся комментированием одной строчки или даже его можно сделать многофункциональым.
например:

template<typename T>
T& get_instance_singletone()
{
   static T t;//работу в многопоточной среде убираем для наглядности.
   return t;
}


или это уже не синглтон?


второй экземпляр может понадобится, а может и не понадобится.
Например есть COM класс, который должен быть синглтоном. и за последние пол года это не изменилось пока)
Синглтоном его делает своя фабрика. Как в этом случае избавится от синглтона? COM сервер — внепроцессный.
А чтобы его переделать в обычный класс, нужно закомментить одну строчку — DECLARE_CLASSFACTORY_EX(...) или добавить еще один класс, который будет от него наследоватся — если нужно 2 класса.
Re[21]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.07.10 09:00
Оценка:
Здравствуйте, enji, Вы писали:

E>Ну т.е. вместо 20 несвязанных друг с другом синглтонов, каждый из которых ничего не знает о других, будет 1 мегасинглтон, который знает и о системе логирования и о загрузке данных через интернет (где-то выше мелькал пример) и о драйверах оборудования, ... Получается этот мегасинглтон заточен под конкретный проект, перетащить его в другой проект в принципе невозможно.


Код конфгурации знает про всё в системе. Сам regisry вообще ни про что не знает.

этот мегасингтон перетаскивается на раз в другой проект.

E>Или же этот реестр будет хранить что-то вроде void*, а затем будет иметься кошмарный интерфейс вида reestr::get<LogSystem>()->log("bla bla")


Реестр будет хранить то, что в него напихал конфигуратор.

E>И чем такой подход лучше?


слабая связанность, теструемость, реюзабельность, прозрачность
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.