Возникала такая проблема. Есть главный класс, объект которого создаётся в мэйне. Есть класс ресивер, объект которого пускуается отдельным потоком в конструкторе главного класса. и есть класс юзерс, объект которого создаётся в конутрукторе главкласса. Мне надо сделать так, чтобы ресивер при определённом условии вызывал метод adduser объекта класса юзерс. Я сделал так. в Конструкторе ресивера получаю ссылку на объект класса юзерс и присваиваю её ссылке внутри ресивера. далее в методе ран(ентри поинт потока) класса ресивера я вызываю adduser через внутреннюю ссылку. А потом подумал, что при дальнейшем росте программы мне придётся передавать как параметр не только ссылку на объект юзерс, но и ещё много всего, а може быть, и на объект главного класса-а это очень плохо(я так думаю). Программу стараюсь писать по принципам ООП(на сколько их понимаю) и хотел бы узнать как правильно реализовывать такую(как я описал) связь между объектами?

Здравствуйте, oleg.bovykin, Вы писали:

OB>Возникала такая проблема. Есть главный класс, объект которого создаётся в мэйне. Есть класс ресивер, объект которого пускуается отдельным потоком в конструкторе главного класса. и есть класс юзерс, объект которого создаётся в конутрукторе главкласса. Мне надо сделать так, чтобы ресивер при определённом условии вызывал метод adduser объекта класса юзерс. Я сделал так. в Конструкторе ресивера получаю ссылку на объект класса юзерс и присваиваю её ссылке внутри ресивера. далее в методе ран(ентри поинт потока) класса ресивера я вызываю adduser через внутреннюю ссылку. А потом подумал, что при дальнейшем росте программы мне придётся передавать как параметр не только ссылку на объект юзерс, но и ещё много всего, а може быть, и на объект главного класса-а это очень плохо(я так думаю). Программу стараюсь писать по принципам ООП(на сколько их понимаю) и хотел бы узнать как правильно реализовывать такую(как я описал) связь между объектами?

Перепиши сообщение. Желательно на русском.

Здравствуйте, oleg.bovykin, Вы писали:

Трудно понять кто кого вызывает...

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

PS Если я правильно понял твой пост

Я хочу написать чат по правилам ооп. Но идёт пока тяжело-даже объяснить примерную структуру не смог(((
Может кто-нибудь подсказать как в идеале должна выглядеть структура чата с точки зрения ооп?
Как реализуется связь между классами/объектами в такой структуре?

Здравствуйте, oleg.bovykin, Вы писали:

OB>Я хочу написать чат по правилам ооп. Но идёт пока тяжело-даже объяснить примерную структуру не смог(((
OB>Может кто-нибудь подсказать как в идеале должна выглядеть структура чата с точки зрения ооп?
OB>Как реализуется связь между классами/объектами в такой структуре?

Какой конкретно чат? Сколько юзеров, какие возможности должны быть? Как собираешься организовать коммуникации?

В принципе, чат — очень простая программа. Едва ли не самое простое и базовое приложение для messaging-based систем.

ГВ>... для messaging-based систем.

Конечно же, message-based.

Чат обычный. У нас в сети есть самописный чат, но кривой. Основан на удп протоколе. При подключении пользователя он посылает бродкаст что он есть(/iamhere <nick>) и бродкаст /who на который клиенты отвечают инфой о себе типа /iamhere <nick>. Я хотел сделать классы сокетворкер(содержит сокет, принимает и посылает сообщения), парсер(обрабатывает строку, полученныю от сокетворкера/готовит строку для посылки через сокет воркер), узерлист(массив, поля: <ipaddress>, <nick>), ну и главный класс чат. Я потому и выбрал самое простое приложение для более простого понимания принципов реализации идей ооп.