член ли команды кэп? или все же есть кэп и его команда?

blue fox, я внимательно прочла вот это и нигде не нашла, что кэп не является членом команды Но можно подумать и заменить формулировку на более рефлексивную.

Короткий Хвост, как бывший проектировщик я легко разрешаю коллизию набором качеств "самобетинг", "член команды" и "кэп"

в случае если кэп член команды, то
проверям наличие самобетинг на "кэп в качестве член команды" , если да, то "кэп в качестве кэп" не бетит "кэпа в качестве член команды", действие не выполняется качеством кэп;
если нет - то "кэп в качестве кэп" бетит "кэп в качестве член команды", действие качеством кэп выполняется :-))
в этом случае самобетинг не равно последнему действию ибо исполняется разными качествами

если кэп отдельно
то все все зависит только от качества самобетинг :-)

blue fox, мы заводим дополнительную структуру на множестве "члены команды", это выводит на другой уровень абстракции

Короткий Хвост, ну да :-))) надо ввести еще одно измерение
это же задачка из разряда сложить 4 правильных треугольника из шести непересекающихся спичек :-))

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

blue fox, т.е. для меня это что-то вроде вопроса, можно ли научиться делить в кольце (не выходя в поля )

Короткий Хвост, нуу вроде размерность и тут явно не задана...

blue fox, в твоём решении подразумевается, что у игроков есть качества (по крайней мере, у кэпа), и что "кэп в качестве кэп" и "кэп в качестве игрока" — разные сущности

blue fox, а расскажи, что такое проектировщик? Кажется, я об этом уже спрашивала, но благополучно забыла ответ Интересно.

Короткий Хвост, нуу не знаю, что по-правильному называется этим словом, а в моем случае читать дальшеты сидишь и придумываешь архитектуру в которой будут комфортно размещаться бизнес-процессы (или технологии по-старому), в моем случае это база данных в которой надо заложить таблицы с индексами для поиска (менять индексы очень сложно, поэтому надо сразу догадаться как все может развиваться, научных способов тут нет, только опыт и интуиция), причем подобрать оптимальное количество таблиц на сейчас и спрогнозировать развитие, например предусмотреть таблицу "заемных" полей для других таблиц, потом на эти таблицы придумать вменяемые и дружелюбные интерфейсы, чтобы скажем в случае текстовых экранов минимизировать нажатия для юзера, закладывать вменяемые структуры для обслуживания сейчас и в развитии, всякие автоматически запускаемые проверки и подпорки и защиты от дурака, а также простые и оптимальные способы для юзеров получить ответ на свой вопрос причем желательно в режиме реального времени, и при этом в пределах его доступа, ну и всякая такая фигня, несколько похоже на работу архитектора наверное.
Чтобы пользователи могли ее подстраивать и развивать под себя без привлечения программистов в большинстве случаев, т.е. предусмотреть еще некие конструкторы для них.
Ну и вот разрешение коллизий тоже всегда интересные задачки, особенно когда бам становится двухколейным и параллельные ветки разрастаются и не встречаются в нужном месте :-))) Не знаю как объяснить нормальными словами честно говоря - просто постоянно вертишь в голове некие многомерные объекты, и пытаешься переложить их на структуры и алгоритмы, и чтобы все работало не абы как а оптимально. Причем эти объекты ты изначально имеешь в виде неструктурированной инфы и всякого словесного поноса, который предварительно надо довести до каких-то схем.
Ну вобщем я почти 20 лет этим с кайфом занималась, но все хорошее рано или поздно заканчивается (

Короткий Хвост, ну да - разделение сущностей, точнее качеств - это для меня привычный прием :-))
например вот есть справочник ну скажем организаций/контрагентов в торговой фирме, каждая запись может участвовать в разных процессах в разных качествах - например, покупатель, поставщик, какой-нибудь агент влияния (например быть источником рекламы), или просто контактным лицом для другой записи, или вот кэпом для какой-нибудь команды и т.д. :-))))
соответственно - запись то одна, а качеств в которых она выступает много, и в зависимости от качества в котором она играет у нее разные правила игры в разных ситуациях, и объекты в которых используется запись в разных качествах - разные.

blue fox, ну и всякая такая фигня, несколько похоже на работу архитектора наверное.
прикольно! Знакомые, что занимаются организацией и анализом бизнес-процессов, немного про это рассказывали. Не совсем то, но похоже на твои рассказы, и тоже интересно и формирует определённый склад ума, видимо. Наверняка похоже на архитекторов и проектировщиков инженерных сооружений, на них я тоже смотрела, тоже потрясающие умения крутить в голове объекты.

разделение сущностей, точнее качеств - это для меня привычный прием :-))
"Любую проблему можно решить выходом на новый уровень абстракции, кроме проблемы слишком большого числа абстракций" Кажется, у нас просто разные идеологии в голове — я в подобных теоретических случаях начинаю не добавлять абстракции, а понимать, что можно извлечь из уже существующей структуры, а что выведет нас за её пределы. Курс общей алгебры, похоже)

Короткий Хвост, а я практик, я начинаю сразу практически решать

blue fox, задачи на работе я тоже практически решаю костылями и велосипедами

Короткий Хвост, ну подпорками и заплатками тоже приходится, но я этого не люблю ((
а изобретать велосипеды люблю, хоть это и недостаток