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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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