==== Об общих принципах построениия программ ====

=== Структуры данных ===

Порассуждаем об организации данных в программе. Если с классическими
конструкциями - списками, деревьями, хэш-таблицами - всё понятно, то по
прикладным структурам, представляющим логику программы, есть много вопросов.

Попробую применить нисходящий подход и построить оптимальную схему организации
данных для двух серверов. Первый - сервер в стиле myrelay, второй - видеосервер
в духе bcast-server.

== Сервер myrelay. ==

Спроектируем простой эхо-сервер, работающий по унифицированному протоколу обмена
сообщениями. Сервер должен быть асинхронным и многопоточным. Также выдвинем
требование переносимости: сервер должен работать под Linux и Win32.

Допустим, что ответы от сервера зависят от общего состояния. Например, сервер
раздаёт клиентам уникальные идентификаторы - возрастающие числа. Обобщённая
схема работы в терминах используемых системных вызовов в Linux:

    socket \
    bind   |
    listen  > Управление соединением
    close  /

    epoll_create \
    epoll_ctl    |
    epoll_wait    > Цикл сообщений
    close        /

    read   \
    write  } Основной функционал: получение и отправка данных

Сразу выделяются два системно-зависимых объекта: сетевое соединение и средства
уведомления о событиях ввода/вывода. Функции управления соединением и событиями
опишем отдельными объектами: Server, Connection и PollGroup.

Чтение сообщений и разбор ообщего формата также можно выделить. Создаём для
этого класс MessageReader.

В отдельный класс удобно выделить каждый новый уровень разбора сообщения.
В нашем примере уровней два: первый представлен классом MessageReader, второй -
уровень разбора эхо-запроса - представми классом EchoServer_MasterServer.

Общее управление соединениями поручим объекту SimpleServer.

Собственно реализация эхо-сервера - класс EchoServer_Master.

   +--> Server
   |
   +--> Connection ----------+
   |                         v
   +--> PollGroup ---> MessageReader ---> EchoServer_MasterServer
   |                                                v
   SimpleServer                             EchoServer_Master

При проектировании в стиле MyCpp все эти объекты оформляются как самостоятельные
Object'ы, связываемые во время исполнения подписками на раличные события.
В рамках подхода libMary такую организацию данных я считаю неэффективной:
слишком много операций выделения памяти нужно для начала обслуживания нового
соединения. Основной недостаток в том, что декомпозиция целого на составные
части диктует менее эффективное, громоздкое представление. Хотелось бы иметь
возможность писать обобщённые реализации составных элементов так, чтобы их
можно было использовать с разными схемами размещения объектов в памяти, в том
числе и с более эффективными, чем "отдельный блок памяти для каждого объекта".

Я не спорю с удобством написания программ в стиле MyCpp, но не согласен с
излишней специализированностью компонентов, которые сразу формляются как
Object'ы.

Вывод: Для каждого компонента нужно выбирать минимально необходимый интерфейс.
Компонент оформляется как Object только если необходимо управлять временем его
жизни извне, причём это управление является частью интерфейса компонента и
заложено в выбранную схему организации данных.

