Цитата:
|
И после этого руководство утвердило его, и было принято решение его взять за основу.
|
Ну... Грязноватый там код. Например, склеивание XML из строк - это очень и очень плохо. Ну и всякие походы по xml вроде firstChild.firstChild надо бы защитить. Формат неожиданный все-таки случайно может придти.
А вот внешнее API вполне приличное. Посмотрите только на public-функции. Они отражают вполне конкретную предметную область и удобны ровно для того приложения, для которого предназначены. Вещи if (<condition>) { sendXML(...); } я бы на исключения переделал. Нехорошо проглатывать ошибки, а так бы оно сразу в debug-плеере вылезло там, где надо. Отлаживать проще. Ну и функцию answer я бы на две разбил, наверное (потому что это разные действия). Внутри можно все переделать и это не затронет внешних клиентов.
Обратите внимание, этот API сделан под конкретную задачу. Т.е. для другой задачи данный конкретный класс не применим - там будут другие типы сообщений, другие события и т.д.
Цитата:
|
Вот как такое может быть: в нём не применено ни одного шаблона, хотя полностью вся реализация XMLSocket, о которой я писал в первом сообщении отражена?
|
А в чем проблема? Качество кода не измеряется количеством использованных шаблонов. Обычно, чем меньше шаблонов, тем API лучше. Конкретно реализацию там можно еще попилить, отдельно на обмен XML и формирование запросов и разрбор ответов разбить. Можно не разбивать, не принципиально.
Кстати, шаблон там есть. eclClient является типичным message bus на прием сообщений от сервера. И для данного сценария работы (асинхронные сообщения) это тоже удобный API.