Пусть у нас есть класс. Реализующий какую-то функциональность.
И вдруг встаёт задача сделать из этого класса Singleton.
Как будем поступать? Делать наследника с глобальной переменной, классовым методом Instance и секцией finalization?
Идея - неплохая, но:
1. Секции finalization зовутся в негарантированном порядке и Singleton может убиться РАНЬШЕ, чем кто-то другой его использует, а мы узнаем об этом только по AV на выходе, или вообще не узнаем - если Singleton написан так, что создастся второй раз (тут бы подумать о чём-то типа AddExitProc).
2. Все подобные наследники будут запрограммированы методом Copy'n'Paste. Некрасиво по-моему.
3. Singleton по-моему должен "переживать" нормально многопоточность. Для этого кроме глобальной переменной - нам понадобится ещё и критическая секция. Будем размножать код по работе с критическими секциями во всех наследниках? По-моему - тоже не комильфо.
Давайте сделаем реализацию Singleton'а примесью?
Тут кстати есть о чём поразмыслить. Хотя бы о том же AddExitProc и гарантии повторного несоздания синглетона при завершении приложения. Или о методе Exists. Ведь нередки случаи (по крайней мере в моей практике), когда Singleton и не надо создавать, а надо лишь проверить его существование. Тут правда с многопоточностью есть проблемы.
Причём ещё сразу хочется отметить тот факт, что синглетоны бывают "объектные", а бывают "интерфейсные". Со вторыми - несколько сложнее. Посему начнём рассмотрение с первых.
... to be continued ...
И вдруг встаёт задача сделать из этого класса Singleton.
Как будем поступать? Делать наследника с глобальной переменной, классовым методом Instance и секцией finalization?
Идея - неплохая, но:
1. Секции finalization зовутся в негарантированном порядке и Singleton может убиться РАНЬШЕ, чем кто-то другой его использует, а мы узнаем об этом только по AV на выходе, или вообще не узнаем - если Singleton написан так, что создастся второй раз (тут бы подумать о чём-то типа AddExitProc).
2. Все подобные наследники будут запрограммированы методом Copy'n'Paste. Некрасиво по-моему.
3. Singleton по-моему должен "переживать" нормально многопоточность. Для этого кроме глобальной переменной - нам понадобится ещё и критическая секция. Будем размножать код по работе с критическими секциями во всех наследниках? По-моему - тоже не комильфо.
Давайте сделаем реализацию Singleton'а примесью?
Тут кстати есть о чём поразмыслить. Хотя бы о том же AddExitProc и гарантии повторного несоздания синглетона при завершении приложения. Или о методе Exists. Ведь нередки случаи (по крайней мере в моей практике), когда Singleton и не надо создавать, а надо лишь проверить его существование. Тут правда с многопоточностью есть проблемы.
Причём ещё сразу хочется отметить тот факт, что синглетоны бывают "объектные", а бывают "интерфейсные". Со вторыми - несколько сложнее. Посему начнём рассмотрение с первых.
... to be continued ...
Комментариев нет:
Отправить комментарий