xStream

Наглядный пример ООП ради ООП... в реализации без архитектуры :-)

Ну, что я могу сказать... Это как раз тот подход, когда люди делают велосипеды Но дело барское. После такого, даже и искать варианты то решение проблемы не хочется. (той, что ты обозначил) Скажу по секрету - это венгерка И что значит "общепринятые"? Я умоляю, пруф в студию. Как минимум к любому языку существует огромное количество code guideline'ов. Быстрее получить решение такое, которое если что, потом можно "проапгрейдить". У меня вот такой критерий. Эм... ну вроде как написали уже: нет "правильного", есть различные подходы. Я предлагаю, чтобы вью содержала в себе весь функционал, который бы настраивался. Как, в принципе, ты и хотел делать.

Это ужасно... А что мешает использовать тот класс, объектом которого является location? Не придется ничего присваивать. Фиг с ней, с венгеркой, но почему, блин, координаты раздельно то? "Более лучше" © Как эффективнее, так и лучше. Правильно - не то слово, в данном случае.

Саш, ты серьезно? О_о Имхо это вообще не так делается: запоминаем ид того, кто должен перейти, и на переход вешаем колбек. Как только перешел в онлайн, выполняем нужное нам таинство. Это не взятие позиций через диалог, а обновление при смене положения юзера, но принцип тот же. Жирным выделила собственно ключевые места. Я не знаю, как под андроид, но думаю, не сильно отлично отличается от iOS или Веб: вьюха отдельно, логика отдельно. Вьюха включает в себя все элементы, а используют вьюху разные модели/вьюконтроллеры и кастомайзят под себя. Сам функционал получения может быть реализован и во вьюхе и где-то вне ее. Получается примерно так: структура положения - хранит координаты некий сервисный класс, который либо получает положение текущее, либо возвращает значение из списка контроллер диалога - показывает вьюху и кастомайзит ее вьюха имеет логику обращения к сервису и просит получить координаты у него Ну, верно, да Просто к положениям это не относится, как и к получению этих положений. И да, не надо плодить разные классы для вьюх.

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

@Andrey07071977, ты не то дал, это инструкция по тому, как делать паблик файлы :-)

Понимат, обнимат. Учитывая, что в этом конкретном исполнении - ооп прототипный, это не имеет никакой особой разницы. Мою песочницу можно тоже сделать в нескольких экземплярах, а при небольшой модификации и в полноценный класс превратить. В iOSразработке сталкивалась с тем, что есть несколько notification manager'ов, но все (программисты) используют только DefaultNotificationCenter Имхо, по понятным причинам - это довольно таки избыточно, да и смысл появляется только в мультипоточных приложениях. Возвращаясь к вопросу: зато объект-событие можно передать куда-то, вплоть до того, что внутрь другого события.

У меня так вообще класс-обертка, который инкапсулирует все взаимодействие с подобным менеджером. Вопрос привычки, стиля и удобства.

Честно говоря, я вообще не понимаю, что ты хочешь. Loadstring вернет результат выполнения строки (как скрипта) и возникнет сигнал с именем-результатом. Но что-то у тебя уже сработало, то есть по сути ты замену сделал самой системе событий - одна единственная функция с ветвлением. А сигналы тут вообще никаким боком.

@Desertir, темплейты всегда в заголовках потому, что у них нет непосредственно кода реализации: классы (функции) создаются по мере надобности. Точнее, шаблон можно вынести в cpp, но это описание никто нигде не увидит, так как подключаются хедеры, а не файлы имплементации. Смутно помню, что в какой-то из новых версий то ли языка, то ли студии, можно определять шаблон в .cpp Ответ на твой вопрос: описание шаблона вместе с реализацией должно быть в зоне видимости всех тех мест, где ты это используешь - это делают в заголовочных файлах.

--тут был абсурд про хешмап, позор на мои седины-- А для чего тогда, если оно никаких преимуществ не даст? Хардкод даст, макаронный код даст, эффективность не даст. Профит в чем?

На минуточку: в луа конструкция t[obj:section()] и набор колбеков со стоками типа if obj:section() == 'fuck_the_millenium" return end внутри выполнятся одинаково. Именно потому, что получение значения по ключу - тот же перебор, по хешмапу. А тут перебор колбеков до первого подходящего - та же табличка и то же сравнение. Разница только в дополнительном микросекундном вызове одной функции. Вообще, знаете как работают конструкции типа t ?

@Desertir, ExtJS - просто надстройка над jQuery, а там довольно просто это сделать. Там тот же стек.

@Murarius, да не. Тут уже разговор иссяк. Краткий пересказ: - тут зырьте крутая штука - ты че за ересь принес? - нормально, не то, что раньше фуфло делали! - эй, мне стыдно, но как умели. Но есть ништяки! - Ну и нафига нужны эти ништяки? Мои круче. - не, ну ты не прав, это полезняк! - о, ребя, чего это вы тут творите? Не ссорьтесь, все ништяки одинаково полезны. - не, нифига! Макароны не надо, надо ништяки! - хм... и правда, ниче так ништяки. - не, ну смотрите, ништяки ваши легко сломать! - ну вот вам способ залатать. - хм, и правда. Ну ок, норм ништяки. - Эй, вы о каких ништяках ваще?

Правда, что ли? :-) Рефакторить микросекундные вызовы? Заниматься копипастой? Нененедевидблейн Да тащемто нет. Подписываются только те, кому надо. И от подобных переборов ты никуда не уйдешь. Главный цимес, что можно это делать динамически (и вот такие реальные случаи были у меня) это, кстати, что такое?