Экземпляр основного класса
 

Как получить доступ к экземпляру основного класса из других классов? Который был создан при запуске флешки. И можно ли создать еще 1 объект основного класса?

Изучите паттерн "Singletone". Создать второй экземпляр можно. При загрузке одной флешки разными лоадерами в один аппдомен именно это и происходит.

вообще, экземпляр текущего класса - это this. Создать новый экземпляр корневого класса можно через new Main();

А как лучше реализовать такую задачу:
При запуске флешки в основном классе создаются объекты других классов, к которым позже надо будет обратиться. Вот как к ним обратиться? Знаю только что при запуске можно вывести ссылки на них из основного класса.

Объекты нужно стараться создавать так, чтобы им не нужно было обращаться по принципу все-ко-всем.
А если уж какому-то объекту нужен тот или иной экземпляр, то его можно передать в виде ссылки в конструктор, например. В отдельных случаях более оправдан будет даже синглтон.
Но создавать кучу экземпляров, чтобы любой из них в любой момент мог добраться до любого другого — это плохая архитектура.

Наверно вам действительно нужно сначала определиться с иерархией вашего приложения. Насколько я понял вы пытаетесь запихнуть все в основной класс а обращаться хотите из других и не знаете как. Лично я бью все на вспомогательные классы а потом уже собираю интерактивную сцену. ИМХО:o

P.S. может я просто не понял проблему =(

Именно задача, которая требует реализации:

Создать текстовое поле, в экземпляре основного класса или в любом другом объекте. И иметь доступ к этому полю из любого класса.

Так воспользуйтесь синглтоном, как я говорил выше. В данном случае это в корне не правильно так его использовать здесь, но это будет проще, чем полностью переделывать архитектуру приложения.

Можете предложить свою реализацию данной задачи? Как правильно это сделать.

тогда вот вам ваш вариант. Изначально в классе в котором хотите обратиться сделайте следующее


и юзайте его по полной без инициализации.

а в главном уже инициализируете

а когда инициализируете класс в котором обращаетесь добавляете

но я бы так не делал стараюсь подобные случаи сводить к самому минимуму.

Добавлено через 1 минуту
да не забудьте импорт сделать туда сюда.

Получается что для обращения из другого класса к уже созданному текстовому полю нужно передать ссылку на объект в котором создано это поле?
Где-то надо хранить ссылки на объекты?

А зачем Вам доступ к текстфилду отовсюду? Старайтесь разделять логику и отображение. Я не впариваю про MVC, отнюдь, но на самом деле, это очень хорошая практика: тестфилдом управляет нечто, что получает команды посредством событий. Это можно реализовать как угодно, можно через модель (это просто класс с набором данных), в которой будут меняться данные и диспатчиться события.

Реализуйте логику по следующему принципу: дети не управляют своими родителями. Они могут сообщить родителю, что они что-то хотят, родитель сам должен принимать решение, как реагировать на просьбу и реагировать ли вообще. На самом деле очень тяжело говорить конкретно-общие вещи, не зная того, зачем Вам вообще это все понадобилось. Давайте свой конкретный пример и тут Вам пояснят. Без всяких MVC на данном этапе.

Зачем доступ? При "проектировании" приложения я создал 1 текстовое поле, в котором должны отображаться различные данные полученные от разных классов. Как пример: при подсоединении к cirrus, при подключении пира, при отключении пира, должно обновляться текстовое поле (За каждое действие отвечает свой класс).

http://imgdepo.ru/show/7177963
Вот так выглядит у меня структура приложения. При его запуске в основном классе создается текстовое поле и объект класса отвечающего за подключения к cirrus, в свою очередь при создании объекта в случае успешного подключения к серверу создается объект класса отвечающего за изменение текстового поля и вызов его методов.
Теперь, получается что надо сохранять ссылку на объект отвечающего за подключение, а ссылку на объект отвечающий за изменение текста не обязательно сохранять. Было бы совсем отлично если можно вызвать из стороннего класса метод основного класса, но как к нему обратиться(к основному классу).
Вот, если можете помочь подредактировать структуру приложения, будет прекрасно.

В основном классе создадим "большие" объекты. Например коннектор к циррусу (или менеджер запросов, не знаю, как у Вас), экземпляр текстфилда (в более обобщенном виде вместо текстфилда — просто некий контейнер с логикой отображения и какими-то элементами визуализации). Все события от коннектора (подключение, разрыв связи и т.д.) ловит экземпляр главного класса, после чего он решает, что делать: сказать контейнеру с отображением, что нужно записать некое сообщение. В данном случае эземпляр главного класса просто выступает посредником в перегонке данных туда-сюда.
Ой как не хочется Вам тут давать MVC или MVVM, но в итоге все равно придете к этому...

То есть отделить отображение от основного класса полностью? Создать отдельный класс отвечающий за создание текстового поля, его параметров и в основном классе создать его экземпляр? А если так сделать, то где-то надо будет постоянно хранить ссылку на этот объект, вдруг потребуется изменить параметры текстового поля, может быть даже не из главного класса.

2PsychoTech прекратите писать чушь.
2Void - задача изначально поставлена неверно.
Читайте как мантру:
МНЕ НЕ НУЖНО ИМЕТЬ ДОСТУП К ЭТОМУ ПОЛЮ ИЗ ЛЮБОГО КЛАССА

ТС и пытался это сделать и эта тема подтверждение. Но вместо помощи, получил кучу упреков от таких же, как и он новичков, которые находятся в стадии "я знаю как не правильно, а как правильно не знаю". Честно сказать и я помочь не могу, так-как не понимаю задумки. ТС могу лишь сказать, что документ-класс, каковым является Main, не принято использовать для инициализации свойств и прочих ... прочих объектов связанных с приложением. В нем нужно лишь инициализировать класс, который будет создавать другие объекты и если нужно, передавать ссылки друг на друга в конструктор или ещё как-то..

Добавлено через 57 секунд
Void, что Вы в итоге хотите получить?

Жаль, я не обладаю способностями подавать информацию в учебной и легко усваиваемой форме. Смысл в том, чтобы правильно расставить "логическую вложенность". У Вас есть вполне конкретная задача: писать лог в текстовое поле. Туда могут лететь не только сообщения из коннектора к циррусу, но и всякая системная информация (например ровно в 00:00 надо написать "чувак, тебе завтра на работу, иди спать", а в 08:00 надо показать "с добрым утром").

Начальной точкой отправления мы имеем экземпляр главного класса. В нем создается экземпляр коннектора, экземпляр класса с таймером (и этими милыми лог-сообщениями) и экземпляр класса с отображением текстфилда, скроллбаром к нему, красивым фоном (этот экземпляр отображения добавлен в дисплейлиста экземпляра главного класса).

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

Далее, экземпляр класса с сигналами таймера (которые в 00:00 часов и 08:00) видит, что наступило время Х. И тоже шлет кастомное событие. Это событие тоже ловит экземпляр главного класса и вызывает какой-то другой метод у экземпляра с отображением, передавая (или не передавая) в параметрах необходимые данные.

Вот и все.

Далее, Вам захочется сделать, например, кнопку дисконнекта. В отображении делаем кнопку, нажатие на которую диспатчит какой-то иное событие "хочу_дисконнект". Экземпляр главного класса его ловит и вызывает метод у циррус-коннектора, который сделает дисконнект.

Циррус-коннектор следом шлет свое событие, которое так же через экземпляр главного класса попадает в отображение через вызов метода и вот в текстфилде красуется строка "дисконнект успешен" или сообщение об ошибке.

Фуф, надеюсь доходчиво объяснил. никаких MVC, просто разделение логики без жестких связей.

Добавлено через 1 минуту
Неверно, это заблуждение. Чем Вам документ класс не угодил и чем он отличается от "другого экземпляра класса", который Вы советуете в нем создать?

Добавлено через 10 минут
А еще можно, чтобы экземпляр главного класса был более тонкой прослойкой, если написать в нем:
То есть событие сразу попадает в хендлер отображения без необходимости экземпляра главного класса собственноручно принимать событие и вызывать метод у отображения. Все зависит от удобства и контекста. Может быть Вы захотите сделать экземпляр главного класса не просто связующим звеном, а непосредственно центром логики — контроллером.

Ага, спасибо. Только вот не понятно одно, получается участвовать в программе должен только 1 экземпляр класса связанным с чатом? Значит в конструкторе главного класса нужно создать объект класса чата и присвоить его переменной, а дальше по коду работать только с данной ссылкой на объект?

Вопрос непонятен. Если я правильно Вас понял, то Вы говорите про коннектор? Да, он один, он только шлет данные и принимает. И говорит еще всем, кто заинтересован, что у него появились новые данные — через события. Он не должен ничего решать за других. Он только делает свое дело и говорит, мол, ребят, тут пришло новое сообщение, кто там хочет, ловите. И шлет событие, которое уходит в отображение или в менеджер обработки или еще куда.

Точно так же с визуальной стороной. Она не должна приказывать никому, что она хочет сделать. Она должна ПОПРОСИТЬ через событие "дисконнект" или "отправить сообщение". То есть она диспатчит событие с текстом нового сообщения (у нас же чат?), а заинтересованный в этом сообщении менеджер запросов ловит это событие и вызывает метод у коннектора sendMessage с передачей текста.

В данной ситуации циррус-коннектор создается в менеджере запросов и только там хранится на него ссылка и нигде иначе. И никто эту ссылку не видит, только менеджер запросов.

Если Вы поймете, как отделить те или иные обособленные вещи в отдельные объекты, ничего не знающие друг о друге, Вы познаете дзен и тогда MVC Для Вас будет как семечки, ибо все будет понятно и не будет сотен этих одинаковых тем с глупыми вопросами по этому паттерну, хотя рядом лежит такая же тема с теми же вопросами и ответами на них, как тут обычно любят делать )

Можно по подробнее о менеджере запросов?

Что конкретно? Это просто класс, который выстраивает очередь запросов и последовательно их отправляет в коннектор, дожидаясь ответа от коннектора. И он же сигнализирует об ошибке в виде отправки события с ошибкой, если коннекор вдруг сообщил о каком-то косяке. Этот менеджер запросов может принять запрос на отправку сообщения и, скажем, проверить, подключен ли коннектор к серверу и, если нет, сообщить об этой проблеме заинтересованному кругу объектов.

http://imgdepo.ru/show/7178683
Вот так примерно? И если не трудно, нарисуйте полную версию.

Пунктирная линия — общение через события.
Сплошная — напрямую, вызывая методы, дергая акцессоры.
CirrusManager — принимает запросы, как-то их обрабатывает и передает непосредственно коннектору. Он же и сообщает об ошибках коннектора.

Думаю, необязательно создавать синглтон если нужный объект всегда на связи, просто статичный класс - для начала неплохо:

В какой-то момент я начал обращать внимание на архитектурные фрэймворки, остановился на swiz