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

O> Есть некая архитектура поделеная на три слоя. Все как положено. Но что делать при запуске приложения?
O> Сейчас это вижу так: создается объект решения с методом Run(), который создает все необходимые объекты всех слоев и связывает их между собой, после чего запускает потоки. Есть другие варианты?

про потоки не понятно...

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

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

O>>> Есть некая архитектура поделеная на три слоя. Все как положено. Но что делать при запуске приложения?
O>>> Сейчас это вижу так: создается объект решения с методом Run(), который создает все необходимые объекты всех слоев и связывает их между собой, после чего запускает потоки. Есть другие варианты?
S>>про потоки не понятно...

O> Некоторые объекты имеют свои потоки и функции Start().

S>>можно попробовать создавать объекты по мере необходимости. это можно сделать реализуая "главные" объекты слоев в виде синглетонов, которые иницализируются при первом к ним обращении "рабочих" объектов. Более того иницализация части "внутреностей" главных объектов может выполняться так же при первом обращении.

O> Ага, это второй вариант — "цепной" запуск.

O> То есть, нет каких-либо критериев для выбора варианта? Я склоняюсь к объекту приложения, который производит инстанцирование всех необходимых классов, настройку их друг на друга и их запуск.

если приложение будет работать в каждом сеансе со всеми объектами, то такой вариант может быть удачным. В централизации иницализации и явном связывании объектов есть плюсы (все в одном месте) и минусы (по мере развития мотед будет становится все сложнее)

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

Попробуй рассмотреть паттерн Builder для создания и связывания сложных объектов.
Вообще же, если ты используешь архитектуру MVC, то естественно тебе нужно создать класс "запуска системы или какой-либо функции", который для каждой задачи создает объекты модели и вида, затем связывает их и запускает потоки объектов модели.

O> Есть некая архитектура поделеная на три слоя. Все как положено. Но что делать при запуске приложения?
O> Сейчас это вижу так: создается объект решения с методом Run(), который создает все необходимые объекты всех слоев и связывает их между собой, после чего запускает потоки. Есть другие варианты?

Есть некая архитектура поделеная на три слоя. Все как положено. Но что делать при запуске приложения?
Сейчас это вижу так: создается объект решения с методом Run(), который создает все необходимые объекты всех слоев и связывает их между собой, после чего запускает потоки. Есть другие варианты?

O>> Есть некая архитектура поделеная на три слоя. Все как положено. Но что делать при запуске приложения?
O>> Сейчас это вижу так: создается объект решения с методом Run(), который создает все необходимые объекты всех слоев и связывает их между собой, после чего запускает потоки. Есть другие варианты?
S>про потоки не понятно...

Некоторые объекты имеют свои потоки и функции Start().

S>можно попробовать создавать объекты по мере необходимости. это можно сделать реализуая "главные" объекты слоев в виде синглетонов, которые иницализируются при первом к ним обращении "рабочих" объектов. Более того иницализация части "внутреностей" главных объектов может выполняться так же при первом обращении.

Ага, это второй вариант — "цепной" запуск.

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

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

S>если приложение будет работать в каждом сеансе со всеми объектами, то такой вариант может быть удачным. В централизации иницализации и явном связывании объектов есть плюсы (все в одном месте) и минусы (по мере развития мотед будет становится все сложнее)

В этом случае еще сложно будет следить за соблюдением внутренних инвариантов создаваемых обхектов.
Что если кто-то забудет перед запуском их проинициализировать/связать?

S>>если приложение будет работать в каждом сеансе со всеми объектами, то такой вариант может быть удачным. В централизации иницализации и явном связывании объектов есть плюсы (все в одном месте) и минусы (по мере развития мотед будет становится все сложнее)
А>В этом случае еще сложно будет следить за соблюдением внутренних инвариантов создаваемых обхектов.

Что такое "внутренний инвариант"?

А>Что если кто-то забудет перед запуском их проинициализировать/связать?

Значит будет exception

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