Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+167
PopupWindow* GameLocations::getCurrentPopup()
{
if(m_curPopup != nullptr && m_curPopup->needsClose())
{
m_curPopup->onClose();
m_curPopup = nullptr;
m_walker->BeginWalk(m_graph->getClosestNode(m_currentLocationId));
}
return m_curPopup;
}
Запостил: 
Kirinyale,
18 Марта 2011
Follow us!
Задача "геттеров" и "сеттеров" - разделение интерфейса и реализации. А какую реализацию они там внутри себя инкапсулируют - это никого не касается и не интересует. Тут не к чему "привыкать" или "не привыкать". Вам дали "геттер" и сказали что он делает и чего он не делает с точки зрения интерфейса и "влияния на игровую логику" (которого, кстати, из примера не видно). Все остальное вас не касается. Пользуйтесь "геттером" правильно, и все у вас будет хорошо.
Я, например, не знаю, что конкрено этот обрывок должен делать, но абстрактный реализационный паттерн в этом примере виден сразу. И насколько можно судить, все сделано правильно. Ничего странного или некорректного иэ этого примера выжать невозможно.
А если у вас с этим возникли какие-то проблемы, то давайте более полный контекст. Но я подозреваю, что ваши проблемы вызваны в первую очередь вашими же выдуманными ожиданиями, которые вы почему-то накладываете на "геттеры".
Если же логика типа "будильник звонит не потому, что пришло время, а потому что на него после этого посмотрели" теперь считается нормальной и называется паттерном - извините. Отстал от жизни со своими выдуманными ожиданиями типа самодокументируемости интерфейса, конст-корректности, прозрачной архитектуры и прочей чепухи.
А практика, кстати, показывает, что проекты с подобными "архитектурными решениями" впоследствии частенько приходится полностью или почти полностью переписывать совершенно новой команде в сжатые сроки после того, как изначальные авторы, "правильно пользующиеся" своим собственным творчеством, успешно их завалят, потратив при этом втрое больше времени, чем было реально нужно.
Что я вижу в этом коде - это GUI-шный элемент popup, т.е. popup window, который может быть закрыт внешним воздействием, т.е. юзером. В данном случае обрабатывается именно такая ситуация: юзер уже закрыл popup, т.е. с экрана этот popup уже исчез, а его соответствующий внутренний объект типа `PopupWindow` еще живет в памяти. Когда реальный popup на экране уже закрыт, соответствующий "мертвый" объект `PopupWindow` помечается признаком 'needsClose()'. Соответственно код, при первой возможности, должен убивать такие внутренние объекты. Это просто синхронная форма garbage collection. Обычный, повседневный реализационный паттерн, придраться в котором абсолютно не к чему.
Вы тут своим примером с будильником пытаетесь утверждать, что garbage collection должен быть строго асинхронным, как будильник, а синхронный - это, якобы, говнокод. Это, простите, полный бред. Должно быть именно наоборот. Не надо совать аиснхронные решения туда, где они ни на фиг не нужны. Просто не надо проводить аналогии между garbage collection и будильниками - это диаметрально противоположные вещи.
В данном примере возникают вопросы лишь по поводу `m_walker->BeginWalk(m_graph->getClosestNode(m_currentLocationId))` . Что это такое - я не знаю. По местоположению и логике вызова я могу лишь с потолка предположить, что это какая-то форма нотификации каких-то subscribers о том, что произошел garbage collection (хотя имена к такой интерпретации не предрасполагают). А вы нам рассказываете, что это, оказывается, какой-то "персонаж внезапно начинает куда то идти"? А где это в исходном сообщении? Почему вы только сейчас вдруг решили нам об этом рассказать?
Если бы это было хотя бы приблизительно тем, что можно предположить по местоположению и логике вызова, имена там были бы совершенно другие. А этого фрагмента здесь бы не было вообще.
`Walker` и иже с ними - термин без устоявшегося значения (по краней мере в моей области деятельности) и никаких дополнительных намеков на его значение в коде я не вижу. Поэтому брать предположеня об этой строчке кода я могу только с потолка.
Не следует ли из этого, что код неуместен, и его надо рефакторить быстро, решительно, дабы не смешивать разные процессы или привести именование к норме?
признаю, неправ