У вас же есть ссылка на соответствующий стандарт?

Ну так примерно набросал. Просто внутренности не стал показывать, в виду костыльности.
Ну и после наведения порядка внутри - АПИ тоже может как-то поменяться. (Статик манагер тоже под вопросом, но вот так вот вслепую не могу точно сказать. Надо смотреть на интеграцию в систему. Пальцем в небо сложно.)
Добавлено через 1 минуту
Не убог. Обычная себе синхронная система. Просто я привык к асинхрону и stateless, потому такое не люблю. Но подход нормальный сам по себе.

Ну гм, тогда я тебя не понимаю.
Сожмём твой код:
Внесём в конструктор то, что ты вставляешь сеттерами (филдами?).
У нас обоих в наших реализациях один запрос – одна команда. Поэтому я вышвыриваю CommandList.COMMAND_BATTLE_TURN из этого кода, внося её в конструктор BattleTurnDto. Зачем? Это DRY. Типа
Поэтому код сжался вот так:
Теперь я прикидываю, что всегда создавая команду я буду её отправлять. Через CommandManager. Это опять же значит, что я могу создать метод execute() внутри BaseCommand, который будет исполнять вот эту строчку:
(в реальном коде это будет выглядеть как-то так)
Ну и, конечно, после её исполнения надо где-то обработать ответ. Обычно я делаю это внутри самой команды: она сама находит нужные модели, расфасовывает данные и прочее, но иногда удобно получить коллбек о том, что команда исполнена в пользовательском коде. Добавляется листенер addCompleteHandler.
Вот так рождается строчка:
На каком шаге это сжатие кода превращает примерно-нормальный в код Александра?

Согласен. Не стал делать в угоду универсальности, а могут быть структурки набором полей поболее двух, тогда конструктор будет унылым.

А вот здесь фейл, потому что эту структуру может слать несколько команд.
Или же одна команда может слать разные структуры(Это уже плохой вариант, но мало ли).
Но в любом случае нигде не было оговорено связи структура == команда, ты искусственно эту связь прикрутил.

См выше. Если не фейлить - то не сожмется.

Рассуждения верные, выводы не очень.
Сразу же вопрос - а зачем было добавлять манагер с таким подходом?
Как бы изначально екзекьют и есть в команде. Его наружу проксит манагер, ты берешь обратно заворачиваешь екзекьют через манагер в команде? О_о Логику совсем не уловил. Убери манагер и будет счастье.

Дальше всё строится на этом твоем примере потому чем дальше тем глубже.

Проще сделать таким вот образом, если сильно хочется:
И тогда никакой манагер тебе никуда не упирается (а он в твоей логике таки никуда не упирается, всеми своими доводами ты от него избавиться пытаешься)

//****************************
И я предпочитаю single responsibility.
структурки - тупо типизация чтоб обжекты не гонять.
Команда - команда, ничего более. Разве что благодаря тому что она асинхронная и ждет ответа - в нее инкапсулировали еще и обработку данных.
Менеджер - не знает чем занимаются команды. Просто холдер. В его задачи входит убивать отработавшие команды или наоборот оставлять список созданных команд, чтоб не пересоздавать. Это уже от желаемой логики зависит, как там системе удобнее будет.

У меня его и нет. Я его "образно" туда всунул, чтобы поближе к твоему примеру. Мои команды - эдакие микро-контроллеры, сами всё знают и умеют.

Я понял, где у нас расходятся мысли. В моём подходе – одна структура-одна команда в обоих направлениях.
То есть, например есть 3 команды: "Добавить в друзья", "Посмотреть профиль", "Пригласить в мой клан" – и все 3 команды отсылают на сервер одну и ту же структуру – маленькую такую, в одное поле – user_id. В твоём случае – ты хочешь действительно слать одну и ту же структуру (дто), а вот я как раз это и считаю фейлом.
Почему? Потому что это попытка агрегации кода, который агрегирован быть не должен. Если есть константа "4", указывающая на версию протокола и константа "4", показывающая максимальное количество одетых колец – то они как бы равны, но это не значит, что они как-то связаны.
Так и в твоём случае твой подход тебя подведёт, когда при добавлении друга добавиться возможность уведомить его (лишний флаг notice, который не нужен в других двух командах), а при приглашении в клан указывать, какого из типов (клан рабочих/пользовательская гильдия/да всё что угодно). Создание новых Dto, расползание их внутри команд. Это не большая проблема в силу Find Usages в IDE, но я нахожу это неудобным. Поэтому я живу счастливо, интегрируя дто внутрь команды. Такие дела.
По мне, с этим есть проблемы. Вообще, SR говорит что "Один класс – одна обязанность" и в целом, ничего более. Ключевое слово здесь класс: любой класс можно разбить на множество других, каждый из которых будет SR. То есть, если я "вошью" поля из дто прямо в команду – то да, SR может нарушиться. Но если я вошью их в, уже по сути лишнюю сущность дто и уже её вставлю как поле команды – SR будет на месте, но загрустит Оккама.

Да, но только не структурка "user_id", а что-то типа: user_params.user_id.
И если вдруг появятся user_params_for_invite отдельно от других - появится еще одна структурка. Но не раньше. Потому что велика вероятность что она и не появится. И вот тут вот имеет смысл включать твоего оккама:)

Возьми вот это:
- Убери из него new, так как каждый раз создавать новую структуру и не следить за ней не ок. Я предполагаю что она в каком-то буфере/холдере/манагере, который либо удалит, либо очистит, либо закеширует после выполнения.
- Сделай так чтоб стартовало не со структуры, а с команды. Потому что по логике ты вызываешь якобы команду, а не данные. И не команду для данных. А В КОМАНДЕ ШЛЕШЬ ДАННЫЕ. Незачем добавлять непонятностей и неочевидностей в код.
- комплит листенер - то с чего начинал ТС. То от чего я пытался уйти. Хочешь вернуть обратно - верни.

получится:
И в этом месте наши мнения сойдутся.

//**********
И я за то что если уж ООП, то лишней ненужной абстрактности добавлять незачем если для этого нет доп-мотивации. Стараюсь объекты соотносить с реальными объектами "из жизни". С логическими сущностями.

Ну, конечно. BattleTurn.getInstance(), Pool.getInstance(BattleTurn), new BattleTurn – это всё не так важно в этом конкретном примере. Я стараюсь визуально облегчить примеры для форума.
Ага, я упоминал в чате, что я Dto сначала не так понял – расценил как часть имени команды. Конечно, создается команда.
Тебя в них смущает, я так понимаю, исключительно вопрос GC / конвенции.
С коллбеками – если положить их в Dictionary с weakKeys, то даже с повисшим коллбеком не будет проблем. Но откуда он может повиснуть, если при всех ошибках этот коллбек тщательно чиститься ?
Что касается конвенции – можно подписываться Event'ом, опять же с weakKey. Опять же, не смотри на addCompleteListener как какую-то законченную идею: это может быть и сигнал, и эвент. Конкретней рассматривается уже в контексте разрабатываемого приложения.

Может я сейчас что-то не то скажу, но кто мешает пользоваться обычным URLLoader и словарем, где ключ — наш лоадер, а значение — необходимая идентификация пришедшего COMPLETE, например "вот это он ответил с какого он раёна", "а вот это он ответил почему такой дерзкий".

оффтоп, но будь осторожен http://gskinner.com/blog/archives/20...ctionary_.html

Оу. Надо же, последний камент от Psycho Tiger невнимательно прочел )) он о том же.