| Appleman |
26.11.2017 22:01 |
Wolsh, по-моему, у тебя нить обсуждения потерялась. Вот, смотри твой первый комментарий, а затем наши поочерёдные реплики.
Цитата:
Сообщение от Wolsh
(Сообщение 1203070)
Статический класс для подсказок хорош тем, что предоставляет один ларек для обращений, или точку входа, или как там. Правда, всем непонятным элементам придется его импортить, чтоб зарегистрироваться, но если их не катастрофически много, то почему бы и нет (а если много, то явно интерфейс требует пересмотра — игрок не должен сидеть и в задумчивости наводить мыша на каждый объект на экране, вытаясь понять что это с помощью подсказок). Если в хинте (тултипе, сорри) раскрывается дополнительная информация (не ЧТО, а ПОЧЕМУ например), то другое дело.. Но тогда надо сначала продумать механику — будет ли элемент сообщать Менеджеру подсказок только текст подсказки, или будет передавать готовый ДисплейОбжект с картинками, шкалами и графиками, который соберет сам.
|
Дальше я спросил, а чем в случае раскрытия "ПОЧЕМУ" нам не подойдёт всё тот же "статический" класс и что мешает добавить туда необходимую логику, на что ты ответил:
Цитата:
Сообщение от Wolsh
(Сообщение 1203077)
Может, почему нет. Только тогда придется заводить отдельные методы с "логикой" для каждого вида тултипов, а что-то мне подсказывает :) что их будет не два и не три.
|
И вот в ответ на это я и спросил, а в чём, собственно, выигрыш в отказе от "статического" класса. Я понял, что в качестве альтернативы на описанный случай ты предлагаешь использовать "обычный" класс с экземплярами. Я об этом и спросил, в чём его преимущество.
И ещё просьба на счёт вью пояснить - это мой первый вопрос был из предыдущего сообщения. Я его ещё короче сформулирую. Правильно ли создавать отдельные "главные" вью или должен быть один главный "командир", который просто в зависимости от текущей ситуации будет выводить разные дочерние компоненты?
|
