Выбрать шаблон проектирования для реализации XMLSocket

[yasha005]

Сообщение от maxkar

Придумать конечно же . Вот в этом в основном и состоит работа программиста (разработчика ПО). Нужно:
1. Понять, чем вообще занимается приложение
2. Понять, как будет устроен обмен с сервером. Подсказка - обмен может быть устроен неоднородно, может быть несколько различных типов обмена.
3. Детализировать и формализовать (не обязательно слишком усердствовать) требования к API (как то обработка ошибок, мониторинг процесса загрузки).
4. Определиться, что может измениться в ближайшее время (неделя, месяц, три месяца, год).
5. Определиться, что вряд ли будет меняться в ближайшее время (месяц, три месяца, год).
6. Сделать draft API. Типичные действия пользователей библиотеки (на момент разработки) должны делаться легко и просто. 90% действий в идеале должны выполняться за 1-3 строчки кода. 1 строчка - идеал, но не всегда достижима. Все зависит от того, насколько "общей" получается задача.
7. Реализовать этот внешний API. О внутренностях можно не очень заботится. При необходимости их можно будет переписать или отрефакторить. Главное, что внешний API будет удобен.
8. На практике отследить, что API действительно удобен. При необходимости исправить API.

Вот примерно в том, что выше, и состоит работа разработчика ПО. А код - это побочный продукт разработки. Через несколько подобных реализаций вы начнете видеть похожие элементы в них и получите несколько удобных кубиков, из которых можно что-то собрать. Только вот "кубики" слишком универсальными все равно не поулчатся. У разных приложений разные требования, разные сценарии работы и т.п. Поэтому процентов 50 вы, может, на кубиках наберете (упрощение API URLLoader'а, какие-то совсем базовые вещи). А остальные 50% все равно придется реализовывать под конкретный проект. То же сетевое API во флеш достаточно высокоуровневое, до API уровня приложения там не так много можно добавить.

1. Само приложение занимается много чем (у меня на его компиляцию, несмотря на то что находится ещё в стадии разработки, уходит порядка 20 минут на компе с 4-хядерным 3-хгигогерцовым процессором) и одним абзацем тут для описания не обойтись
2. Разумеется обмен с сервеном будет неоднородным, единственное что объединяет обмен данных между собой, это то что они в XML формате
3. Обработка ошибок, мониторинг процесса передачи данных, парсинг данных после их принятия с сервера из XML в объект, формирование данных для отправки их на сервер из объекта в XML
4. Возможно, добавятся новые XML объекты (как приёма, так и передачи данных)
5. Возможно, изменятся существующие XML объекты
6. Вот с этим сложнее, почему-то на практике получается, что я хоть и отправляю одни какие-либо данные ввиде объекта-параметра методу нужного класса. В итоге получается что в этот объект приходится запихивать кучу функций, таким образом не получается уложиться в 1-3 строчки.
7. Если это построение структуры, то беру за основу либо шаблон Компановщик, либо Декоратор; если это какое-либо поведение, то беру за основу либо шаблон Наблюдатель, либо Состояние
8. В том плане что шаблон проектировани удобен - тут сомнений нет, другое дело, что он не всегда в тему может оказаться.


За совет, спасибо

Добавлено через 6 минут

Сообщение от expl

2 yasha005: Это тот случай, когда надо использовать свичи и не плодить классов.

По мне так проще в контекстном классе, метод, который содержит свитчи объявить новый экземпляр класса в каждом кейсе и передать в него this, чем ростить один большой класс и складывать всё туда

Добавлено через 9 минут

Сообщение от gagaga

вы тратите слишком много времени на ерунду (комментирование закрывающих скобок это вообще фаталити)... пишите легкий для восприятия код KISS - keep it simple stupid. Правильно декомпозируйте код, давайте методам понятные имена и всё у вас получится.

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