я бы послушал Котяру и сделал элементарную MVC, которую потом уже обкладывайте шаблонами со всех сторон как хотите.

есть некий контроллер , управляющий IO ..в нем создается коннектор, который гонят тупо сериализованные под свой формат данные. есть модель, наследник диспатчера (ну или своя реализация нотификаций).
коннектор получает пакет данных и сует их в модель (где будут сериализовываться данные сейчас не принципиально), модель уведомляет об изменениях всех подписчиков, коим в классическом варианте является вид.

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

может сумбурно написал..звиняюсь )

Мне вот тоже на работе коллеги сказали: Яша, всё х..ня, давай по-новой.

Немного погуглив, наткнулся на такой вот класс (в прикреплении) всего в одном as файле. И после этого руководство утвердило его, и было принято решение его взять за основу. Вот как такое может быть: в нём не применено ни одного шаблона, хотя полностью вся реализация XMLSocket, о которой я писал в первом сообщении отражена?

Ну... Грязноватый там код. Например, склеивание XML из строк - это очень и очень плохо. Ну и всякие походы по xml вроде firstChild.firstChild надо бы защитить. Формат неожиданный все-таки случайно может придти.

А вот внешнее API вполне приличное. Посмотрите только на public-функции. Они отражают вполне конкретную предметную область и удобны ровно для того приложения, для которого предназначены. Вещи if (<condition>) { sendXML(...); } я бы на исключения переделал. Нехорошо проглатывать ошибки, а так бы оно сразу в debug-плеере вылезло там, где надо. Отлаживать проще. Ну и функцию answer я бы на две разбил, наверное (потому что это разные действия). Внутри можно все переделать и это не затронет внешних клиентов.

Обратите внимание, этот API сделан под конкретную задачу. Т.е. для другой задачи данный конкретный класс не применим - там будут другие типы сообщений, другие события и т.д.

А в чем проблема? Качество кода не измеряется количеством использованных шаблонов. Обычно, чем меньше шаблонов, тем API лучше. Конкретно реализацию там можно еще попилить, отдельно на обмен XML и формирование запросов и разрбор ответов разбить. Можно не разбивать, не принципиально.

Кстати, шаблон там есть. eclClient является типичным message bus на прием сообщений от сервера. И для данного сценария работы (асинхронные сообщения) это тоже удобный API.

Вот с таким кодом на руках уже можно начинать оптимизировать.