Шаблон проектирования (Design Pattern) (комментарии) (3 стр)

Соломон
> Вы имеете что то против ООП?
Нет, но надо это использовать грамотно, а не пихать шаблоны ради шаблонов везде и всюду.

ЗЫ Фанатики паттернов, почитайте лучше KISS, YAGNI & DRY :)

Погодите, погодите, какие же это проблемы инициализации он решает? Он же их наоборот, создает!

Ну и потом, все это уже давно было: http://www.gamedev.ru/flame/forum/?id=88937 (и дальше по ссылкам)

nes
> Самый бесполезный шаблон, необходимый разве как защита от дурака.
+1

gammaker
> Желательно какой-нибудь более реальный пример, чтобы я сразу понял, что без синглона тут не обойтись.
Менеджер текстур в игровом движке.
Менеджер звуков.

Хотя если вы предпочитаете использовать глобальные объекты напрямую - флаг вам в руки.

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

Feo
>использование глобальных переменных в мультипоточной программе - плохой тон
Да не, это просто кривой С++ не умеет их в мультипоточке.

nes
> Да не, это просто кривой С++ не умеет их в мультипоточке.
Кривой C++ даёт возможность программисту решить как поступить с синхронизацией памяти, в то время как языки высокого уровня (или их виртуальные машины) решают этот вопрос за программиста.
Тут каждый в праве решать сам что выбрать, одним нравится быть под каблуком ;) другие любят держать всё под своим контролем.
А так, ты бы еще на кривой ассемблер пожаловался, что там нужно знать адрес функции, что бы её вызвать, если это конечно не сарказм :)

CasDev
> Хотя если вы предпочитаете использовать глобальные объекты напрямую - флаг вам
> в руки.
У меня текстуры управляются сами, специального класса TextureManager нет. Используется только глобальная статическая переменная в файле Texture.cpp, то есть наружу она не вылезает. Со звуками аналогично.

Feo
> инкапсуляция же
И в чём конкретно она страдает без синглтонов? Я не вижу никаких проблем с инкапсуляцией.

Feo
> использование глобальных переменных в мультипоточной программе - плохой тон
Но наверное это в том случае, когда они у всех на виду? А если они доступны только в одном .cpp файле?
Чем вообще в плане многопоточности отличается TextureManager::GetInstance()->LoadFromFile от Texture::FromFile?

Feo
> синглтон это и есть статический член класса со статическим геттером.
Я имел в виду статические функции без самого объекта. Да, их нельзя наследовать. Ещё много чем они отличаются от синглтонов, но разве их и так не достаточно?

Feo
Асм для своей задачи идеален, ничего лишнего, а вот кресты это старая распиаренная херовина,
которую давно пора выбросить на помойку,
надеюсь что мелкософты в скором времени напишут свой C#++,
не уступающий крестам по скорости.

gammaker
> Я не вижу никаких проблем с инкапсуляцией.
Беру твою переменную, присваиваю ей nullptr / newTextureManager() и т.п.
Твое определение инкапсуляции - в студию.

gammaker
> И в чём конкретно она страдает без синглтонов? Я не вижу никаких проблем с
> инкапсуляцией.
Так я и не отрицаю, что есть другие паттерны для инкапсуляции данных. Синглтон, наверное, самый "централизованный" паттерн из всех :)
gammaker
> Но наверное это в том случае, когда они у всех на виду? А если они доступны
> только в одном .cpp файле?
> Чем вообще в плане многопоточности отличается
> TextureManager::GetInstance()->LoadFromFile от Texture::FromFile?
в плане многопоточности - ничем, и ты сам это знаешь. Разве что мьютекс может быть членом TextureManager'а, в то время как у тебя его тоже нужно делать статическим. А если он нужен в нескольких методах? выносить его в глобальную область видимости. дело конечно твоё, но лично я противник глобальных переменных. как говорится, глобальные переменные - глобальные проблемы.
gammaker
> Я имел в виду статические функции без самого объекта. Да, их нельзя
> наследовать. Ещё много чем они отличаются от синглтонов, но разве их и так не
> достаточно?
мы же про ООП сейчас разговариваем? а то получается палка о двух концах:
ты мне: зачем ООП, когда есть процедурное?
я тебе: зачем процедурное, когда есть ООП?
:)
nes
> а вот кресты это старая распиаренная херовина,
> которую давно пора выбросить на помойку,
> надеюсь что мелкософты в скором времени напишут свой C#++,
> не уступающий крестам по скорости.
не напишут. пробовали уже: Managed C++, C++/CLI
в остальном - без комментариев

CasDev
> Беру твою переменную, присваиваю ей nullptr / newTextureManager() и т.п.
Так переменная - это не указатель, а объект, которому ничего нельзя присвоить. Например лог - это объект, которые сначала не делает ничего. Но потом к нему можно прикрутить вывод в файл или в несколько файлов.
Либо не объект, а что угодно, но доступное только одному классу, не вылезая наружу.
А вообще про инкапсуляцию с файлов началось.

Feo
> А если он нужен в нескольких методах? выносить его в глобальную область
> видимости. дело конечно твоё, но лично я противник глобальных переменных. как
> говорится, глобальные переменные - глобальные проблемы.
Нескольких методах одного класса Texture? Объявить его в Texture.cpp в глобальной области видимости как static, извне он будет недоступен, даже через extern. Какие проблемы?

Feo
> мы же про ООП сейчас разговариваем? а то получается палка о двух концах:
> ты мне: зачем ООП, когда есть процедурное?
> я тебе: зачем процедурное, когда есть ООП?
Нет, я не это имел в виду. Я имел в виду, что менеджеры не нужны (а следовательно и их синглтоны). Пусть класс сам менеджит себя. А если менеджеров нет, то где ещё можно встретить синглтон? По крайней мере, если подумать и те объекты, которые теоретически могут существовать в нескольких экземплярах, не делать синглтонами. Даже если на практике он всегда один.

gammaker
> Пусть класс сам менеджит себя.
хорошо, практикуй и дальше продвинутые антипаттерны.

CasDev
> хорошо, практикуй и дальше продвинутые антипаттерны.
А в чём здесь ты увидел антипаттерн? В отсутствии паттерна?

gammaker
Класс сам себя менеджить не должен, иначе это не класс, а какая-то помойка ("божественный объект" - название антипаттерна).